目录

• 恋词强化2
• 计网C5
  • 5.1 传输层概述
  • 5.2 UDP 协议
  • 5.3 TCP 协议特点和 TCP 报文格式
  • 5.4 TCP 连接管理
    • TCP 的连接过程（三次握手）
    • TCP 的连接释放（四次握手）
  • TCP 可靠传输
  • TCP 拥塞控制
  • TCP 拥塞控制
  • 总结
• 计网C6
  • 6.1 网络应用模型
    • 网络应用模型-C/S
    • 网络应用模型-P2P
  • 6.2 DNS 系统
    • 域名服务器
    • 域名解析过程
  • 6.3 文件传输协议 FTP
  • 6.4 电子邮件
    • POP3 协议
    • IMAP协议
  • 6.5 万维网和HTTP协议

恋词强化2

---

计网C5

5.1 传输层概述

• 端口号只具有本的意义，在因特网中不同计算机相同端口号是没有联系的
• 熟知端口号：

• 套接字 Socket = ( IP地址：端口号 )，他唯一地标识网络中的一台主机和其上的一个应用（进程）

5.2 UDP 协议

• UDP的优点

  • 无需建立连接,节省数据传输的时间,DNS的解析使用UDP,HTTP不使用UDP
  • 无连接状态,TCP是需要建立连接的
  • 减少首部开销, UDP首部占有 8B,而TCP首部占有20B
  • 由于UDP只管发送,不关注是否有无收到,不需要确认等待,所以应用层能更好的控制发送数据和发送时间,因此网络中的拥堵并不会影响主机的发送效率,针对一些实时性要求较高的的应用需要稳定的发送速度,如流媒体,能容忍一些数据的丢失,但不能容忍较大的延迟,UDP正好满足了这些应用的需求。

• 使用范围

  • 使用于一次性传输较少的数据,如DNS,SNMP,这是因为可靠性不高,需要多发送几次
  • 它其虽然不回等待确认接受方是否成功接受到,但也是尽量努力的去交付数据,因此所有维护传输可靠性的工作转移到了用户应用层去完成,应用进程根据具体的要求来设置可靠的传输机制。
  • UDP也是面向报文的，发送方UDP对应用层提交的报文,在添加首部后就向下交互给了IP层,不合并也不拆分,而是保留这些报文的边界; 同样的接受方UDP对IP层提交的数据拆除首部之后得到原始的报文
  • 因此UDP的最小传输单元是报文，一次交互一个完成的报文,此报文无法进行分割

• 举个古代通信的方式

  • TCP: 通过人工传送书信,必须当面交换本人确认并返回信息,可靠连接
  • UDP: 通过鸽子传送书信,鸽子在路上容易被劫杀,迷路,饿死,累死,跑路,联络方搬家,鸽子找不到等等,所以通常需要多发送一些鸽子,所以它是不可靠的连接。(这里在暂时不考虑人在路上传送意外的情况)

• UDP的首部格式

  • 源端口: 发送报文的进程端口
  • 目标端口: 接受报文的进程端口
  • 长度: UDP数据报的长度,包括首部数据,最小值为8
  • 校验和: 检测UDP数据在传输过程中是否有出现差错,有错则丢弃,该字段是可选的,当源主机不想计算时直接将令该字段全部为0.

• UDP的校验,UDP是通过伪首部来进行校验,伪首部只有在计算检验和的时候才会出现,不向下传递也不会向上递交

  • 下图0代表全名字段
  • 17是一个协议字段值,指定传输层使用哪种协议,UDP的协议字段值为17,还有很多的其它协议字段
  • UDP长度: UDP的首部8bytes加上UDP数据部分的总长度

• 检验过程-发送端工作

  • 加上伪首部,(伪IP首部)
  • 全0填充检验和字段
  • 全0填充数据部分(UDP数据报以4字节单位串连,不足部分补0)
  • 伪首部+首部+数据部分 采用二进制反码求和.
  • 把求和反码填入填入检验和中(校验和)
  • 去掉伪首部发送. 所以说伪首部是检验过程中间临时生成的辅助数据,使用完就去掉

• 检验过程-接受端工作:

  • 填写上伪首部
  • 伪首部+首部+数据部分采用 二进制反码求和(所谓的二进制反码求和，即为先进行二进制数取反，然后求和，如果最高位进一，则保存到最低位即可。)
  • 结果全部为1则说明没有差错,否则丢弃该数据,交给上层应用并加上差错警告

5.3 TCP 协议特点和 TCP 报文格式

• TCP协议是在不可靠的IP层上实现的可靠数据传输协议,它主要解决传输的可靠,有序,无丢失和不重复问题,主要特点如下:
  • TCP是面向连接的传输层协议
  • 每个条TCP连接包括2个端点,它是基于点对点通信的(不同主机的两个进程端口通信)
  • TCP提供可靠的交互服务,提供数据无差错,不丢失,不重复且有序的传输
  • TCP提供了全双工通信，允许通信双方的应用进程在任何时候都能收发送数据所以TCP的两端都需要设置发送缓存和接受缓存。
  • 面向字节流: TCP把应用程序交下来的数据视为一连串的无结构的字节流,例如AsyncSocket中的数据传输均需要封装层data发送,我们可以在字节流的首部加上固定标志位来定义的自己的格式,通过此方法封装一套自己的协议,但这些都属于私有的协议,业界已有很多通用的协议。

• TCP报文段格式
  • TCP的报文段首部最短是20B,后面有4N(4字节的整数倍),是根据需要添加的的可选项。
  • 源端口可目标端口各占 2B,同UDP一样,均需有发送和接受的端口,因为是面向应用层的,实现进程的数据通信
  • 序号字段: 占4B, 因为TCP是面向字节流的,所以TCP传送的数据中每个字节都编上一个序号,该序号表示的是数据的第一个字节的序号.(在发送时TCP会将字节流进行分组发送,为每组数据的第一个字节指定一个序号,用于告诉接受方它门的顺序,防止数据错乱), 本次发送的数据第一个字节的序号
  • 确认号字段: 同样也占4B,它和序号字段是一对, 本次请求接收对象的数据的第一个字节的序号,通常会结合上下文场景接受的序号加1加上接收的数据长度再次请求
  • 数据偏移: 占4bit，即首部长度,这是因为TCP的首部可以根据需要进行扩展,这里指定数据距离原始的20B最小的TCP首部大小的偏移位置,用于区分TCP首部的扩展字段
  • 紧急位URG: 当URG=1时,标明紧急指针字段有效,他告诉系统报文段中有紧急数据,应当尽快传输, URG需要配置紧急指针(URG point)使用,从数据的第一个字节到紧急指针所指的字节就是紧急数据.
  • 确认位置 ACK:全称acknowledge, 只有当ACK=1的时候确认号才有用。TCP规定在连接建立后所有传送的报文都必须要把ACK设置为1.
  • 推送位置PUSH: 当PUSH=1的时候,TCP要求将此报文尽快的传递给应用进程,不用等到整个TCP的发送缓存都满的时候再发出。
  • 复位RST(Rest): RST=1的时候说明TCP连接出现了严重的差错(如主机崩溃或其它原因),需要释放连接后重新连接.
  • 同步位(SYN): 同步SYN=1的时候说明TCP是一个请求连接或连接接收报文。SNY=1, ACK=0时,标明这是一个请求连接报文,若对方同意连接则返回 SYN=1, ACK=1.
  • 终止位(FIN): 释放一个连接.FIN=1标示此报文的发送方数据已经发送完毕,并要求释放连接。
  • 窗口字段: 占2B,2个字节,它指允许对方发送的数据量,接受方的数据缓存空间是有限的,为了避免发送过多数据,设置一个窗口大小,告诉发送方最多能接受多少数据。
  • 紧急字段指针: 配合URG搭配使用,从数据第一个字节到紧急字段指向的字节为紧急数据,需要优先处理。
  • 选项字段: 长度可变,占4字节的整数倍,主要是用来对TCP基本的首部字段不满足时候的补充,TCP最初规定了一种选项,即最大报文长度(Maximum Segment Size, MSS), MSS是TCP报文段中的数据字段的对打长度.
  • 填充字段: 为了是这个首部长度为4B的整数倍,方便协议格式的统一,程序猿阅读,以及代码编写时的首部协议字段进行解析。

5.4 TCP 连接管理

TCP 的连接过程（三次握手）

• 连接过程

  • step1: 发送请求连接请求报文: SYN=1, seq=x(随机),ACK默认为0, 其中SYN为TCP首部中6个关键字段之一,代表请求建立连接或返回连接报文,这里搭配seq的随机数,标示请求连接; seq则是指TCP首部中的序号,随机先发送一个数据问候接受方; 需要特别注意,此处是不需要传入ack确认序号的,因为没有对方的任何信息,不知道要获取接收方具体的数据.而且可以看到初始化的ACK默认为0,这也说明了此时的确认序号ack是么有意义的
  • step2:服务器为TCP连接分配缓存和变量,并向客户端返回确认报文段,允许连接,无应用层数据 ·SYN=1,seq=y(随机),ack=x+1, 在服务器回复同意连接报文段的同时,发送数据字节流序号seq为随机分配(因为发送方的请求连接时的请求确认序号ack没有意义),同时将自己的ack确认序号设置为发送的序号+1(ack=x+1,表示希望得到客服端的下一个字节流的数据)
  • step3: 客服端为TCP连接分配缓存变量和,并向服务端返回确认报文,同意服务端的请求连接建立,可以携带数据(SYN=0, ACK=1, seq=x+1,ack=y+1, seq=x+1是因为请求确认序号为ack=x+1,ack=y+1是因为发送方的seq=y.)

• TCP的洪泛攻击: 从上面可以看出,客服端第一次发送请求报文后,服务器会初始化缓存资源并并回复客户端同意并请求和客户端建立TCP连接,此时如果客户端为攻击者不进行回复,而是反复的请求SYN=1,seq=x(随机),则会造成服务器大量的TCP连接被挂起,造成CPU和内存的浪费,最终死机无法工作; 通常需要设置 SYN Cookie 来进行限制.

---

TCP 的连接释放（四次握手）

• step1: 客服端发送连接释放报文,停止发送数据,主动关闭TCP

  • FIN=1, seq=u, FIN为结束连接标志符,seq为本次发送的数据

• step2: 服务端返回一个确认报文段,客服端这个方向的连接就释放了,此时处于半关闭状态

  • ACK=1,seq=v,ack=u+1, 此处seq为v,是因为发送方seq=u,服务端检测到有序需要传送,先把每发完的数据发送出去

• step3: 服务端发送完后去,就发出连接释放报文段,主动关闭TCP连接.

  • FIN=1, ACK=1, seq=w,ack=u+1,seq=w是根据服务器第二步发送的数据量字节序号累加的,step2,step3之所以两次的请求确认序号都是ack=u+1,是因为在第一步客服端释放连接时的序号为u,服务端请求的下一条数据自然是u+1了。

• step4: 客服端返回一个确认报文段,等到时间等待计时器设置的2msl(最长报文寿命)后,连接自动关闭

  • ACK=1,seq=u+1,ack=w+1, 等待的原因,是为了防止此报文段丢失,导致服务端重新执行第三步骤.

• 关键点

  • 从上面的过程分析, TCP请求连接和断开连接分别为3步和4步
  • 在请求连接和断开连接的过程中,它们的ack和seq初始值都是随机产生的,后面每次握手确认,需要在原来基础上+1
  • 为了保障数据报文的有效接受,最后关闭的时候需要等待一定的时间,确保发送的报文没有失败再关闭。

TCP 可靠传输

TCP实现可靠的传输机制主要是通过以下4个步骤来实现的：

• 校验: 与UDP校验一样,通过创建伪首部校验。
• 序号: 对字节流分块传输,并对每一块的第一个字节标上序号,一次发送。 通过ack请求序号和seq本次发送的序号实现。
• 确认: 通过在一定的等待时间内检查发送的序号最终是否连续,累计确认,没到达就要求重传。
• 重传: 在规定时间内没有收到接受方的确认,对报文进行重传,即超时重传。
  • TCP采用自适应算法,动态改变重传时间RTTs(加权平均往返时间), Re transfer time.
  • 冗余ACK(冗余确认): 当比期望序号达的失序报文到达时,就发送一个冗余的ACK,指名下一个期待的字节的序号
  • 如果发送方收到了3个冗余的ACK,则确认这个报文段丢失,需要重传,这种方式称为快速重传。

TCP 拥塞控制

• TCP利用滑动窗口机制来实现流量控制
• 在通信过程中,接受方根据自己接收缓存的大小,动态的调整发送方窗口的大小,即接接收窗口rwind(接收方设置确认报文段的窗口字段来将rwin通知给发送方),发送方的发送窗口取接收窗口rwnd和拥塞窗口cwnd最小值
  • TCP为每一个连接设置有一个持续计时器,只要TCP连接的一方接收到对方0窗口通知,就启动一个持续计时器
  • 若持续计时器设置时间到期,就发送一个零窗口的探测报文段,接收方收到探测报文段时给出现在的窗口值
  • 若窗口值仍然为0,那么发送方就重新设置持续计时器。
  • 通过这个机制可以打破窗口为0的限制。避免了接受缓存溢出时窗口为0互相等待的局面。

TCP 拥塞控制

• 出现拥塞的条件:

  • 单位时间类接受到的资源小于自己所需要的资源,如看电影丢帧卡顿,游戏数据上抛延迟等等
  • 很多原因都会导致拥塞: 如网络性能变坏,吞吐量下降,路由器坏损,丢包率多,算法出现bug,

• 拥塞控制:

  • 防止过多的数据注入到网络中: 针对网络资源的所有主机协调上网,如分时段,分带宽,全局性的管理

• 基于下面条件固定来讨论
  1. 数据单向传递,而另外一方只负责确认
  2. 接受方总是有足够大的接受空间,因而发送窗口的大小取决于拥塞大小
     • 发送窗口 = Min(接口窗口rwnd, 拥塞窗口cwnd)
     • 接受窗口: 接收方根据接受缓存设置的值,并告知发送方,反应接受方容量
     • 拥塞窗口: 发送方根据自己估算网络用塞程度而设置的窗口值,反应网络当前容量

• 慢开始和拥塞避免
  • 慢开始和下载视频刚开始慢,一段时间后速率稳定下来的特点很类似
  • 横轴为发送的报文段,根据一个传输轮次(发送一个报文到接受，RTT)判断当前的拥塞情况,调整窗口大小
  • 一个往返时延RTT: 开始发送一批用塞窗口内的报文段到开始发下一批用塞窗口内报文段的时间,单个和按最近时间段批量统计,视情况调整矿口.

• 快重传和快恢复
  • 3个重复的ACK确认说明期待的序号没有到达,需要重传, 表明窗口需要调整,提前避免大量重传

总结

---

计网C6

6.1 网络应用模型

网络应用模型-C/S

• 客户端/服务器模型(C/S)

  • 服务器处于监听状态,需要持续运行
  • 客户机发起请求,并等待接收结果
  • 服务器收到请求后,分析请求,进行必要的逻辑处理,并将结果返回给客户机

• C/S特点

  • 地位不平等,服务器通过权限限制客户机的增删该操作,来达到管理客户机,或进行其他受限活动
  • 客户机之间不能直接通信
  • 扩展性不佳,都是围绕服务器请求数据,受限于服务器硬件和网络带宽

网络应用模型-P2P

• 特点,优点

  • 减少服务器压力,去中心化,可将任务分配到各个节点,平衡工作，如流媒体对,区块链技术等
  • 多个客户机可以共享文档
  • 可扩展性高
  • 网络健壮,挂了一台,还有很多替补

• 缺点

  • 在获取数据的同时,还要提供其他服务,占用较多流量,目前已占用50%～90%的流量，使得网络变得拥塞,各大ISP(互联网服务器供应商)通常对P2P应用持反对态度

6.2 DNS 系统

域名服务器

• 根域名服务器:共13个,知道所有顶级域名服务器的IP地址,管理顶级域(如.com),并不直接把待出查询的IP地址转换为域名,而是告诉本地域名服务器下一步影单找哪个顶级域名服务器进行查询。
• 顶级域名服务器: 管理顶级域名服务器注册的所有二级域名，收到DNS查询请求时,就给出响应的回答（可能是最后的结果,也有可能是下一步应当查找的域服务器的IP地址）
• 授权域名服务器(权限域名服务器): 每台足迹都必须在授权域名服务器处进行登记,为了更加可靠的工作,一台主机至少有两个授权域名服务器,实际上,许多域名服务器都同时充当本地域名服务器和授权域名服务器，授权域名服务器总能将其管辖的主机转换为主机的IP地址
• 本地域名服务器: 每个英特网的服务器提供者(IPS)，都可以拥有一个本地域名服务器,当主机发出DNS查询请求时，这个查询请求报文就发送给主机的本地域名服务器。

域名解析过程

• 向本机域名服务器查询是递归查询
• 本机域名服务器向根域名服务器查询是迭代查询
• 访问y.abc.com过程
  • 客户机向本地域名服务器发出DNS请求报文
  • 本地域名服务器接收到请求后,查询本地缓存,若没有该记录，则以DNS客户的身份向根域名服务器发出解析请求
  • 根域名服务器收到请求后,判断是否属于.com域名,将对应的顶级域名服务器器地址dns.com的IP地址返回给本地域名服务器.
  • 本地域名服务器向顶级域名服务器dns.com发出解析请求报文
  • 顶级域名服务器dns.com收到请求后,判断该域名属于abc.com域,因此将对应的授权域名服务器dns.abc.com的IP地址返回给本地域名服务器。
  • 本地域名服务器向授权域名服务器 dns.abc.com发起解析请求报文
  • 授权域名服务器dns.abc.com收到请求后,将查询结果返回给本机域名服务器
  • 本机域名服务器将查询结果保存到本地缓存,同时返回给客户机。

6.3 文件传输协议 FTP

• File Transfer Protocol: 是因特网上使用最广泛的协议

• FTP提供交互式的访问,允许客户指定文件类型和格式,并允许文件具有只读权限,屏蔽了计算机的细节实现,适合在异构网络中任意计算机之间传送文件.

• FTP功能:

  • 提供不同主机(硬件系统可以不同),文件传输能力
  • 以用户权限管理的方式提供对远程FTP服务器上的文件管理能力
  • 以匿名的FTP的方式提供公共文件共享的能力

• FTP采用了C/S的工作方式,使用可靠的TCP传输服务

• 一个FTP服务器同时可以为多个客户进程提供服务

• FTP服务器由两大部分组成: 一个主进程,负责接收新的请求,另外有若干个从属进程,负责处理单个请求

  • FTP的工作步骤

• 打开21控制端口,使客户端能够访问

• 等待客户进程发送连接请求

• 启动从属进程等待客户进程发来的请求,主进程和从属进程并发执行,从属进程对客户进程的请求处理完毕后即终止。

• 回到等待状态,继续接受其他客户进程的请求

FTP服务器必须在整个会话期间保留用户的状态信息，特别是服务器必须把指定的用户账户与控制联系起来,服务器追中用户在远程目录树上的当前位置。

• FTP-控制连接:

  • 服务器监听21号端口,等待客户连接,建立在这个端口上的连接称为控制连接,控制连接用户传输控制信息(如连接请求,传送请求等),
  • 控制信息以7位的(ASCII)格式传送
  • 客服发出的传送请求通过控制连接发送给服务器端的控制进程,控制连接并不用来传送文件.
  • 在传输文件的时候还可以使用控制连接来终止文件传输命令,因此控制连接在整个回话期间一直保持打开状态. (类似一个父进程可以同时管理多个子进程)

• FTP-数据连接:

  • 服务器端端控制进程在接受到FTP客户发来的文件传输请求后,就创建数据传送进程和数据连接，
  • 数据连接用来传送客户端和服务器端的数据传送进程
  • 数据传送进程实际完成文件的传送,在传送完毕后关闭数据传送连接并结束运行
  • FTP使用了一个分离的控制连接, 修改远程文件需要先下载再上传，在NFS文件系统下,允许复制远程文件小部分片段。

6.4 电子邮件

• 概念: 电子邮件是因特网上一种一步通信的方式

• 由三部分组成

  • 用户代理(User-Agent,UA),客户端邮件应用,用于和邮件服务器通信。-邮件服务器, 收发,通知
  • 电子邮件使用的协议.(数据报的封装格式)

• 邮件的收发过程

  • 发信人调用用户代理撰写邮件(邮件客户端软件),用户代理用SMTP把邮件传送给发送方的服务器
  • 发送方将邮件放入到邮件缓存队列中,等待发送
  • 运行发送方邮件服务器的SMTP客户进程,发现邮件缓存中有待发送的邮件,就向运行在接受方邮件服务器的SMTP服务器进程建立TCP连接。
  • TCP连接建立以后,SMTP客户进程开始向远程SMTP服务器进程发送邮件，当所有待发送邮件发送完成后,SMTP关闭建立的TCP连接
  • 运行在接收方邮件服务器的SMTP服务器接受到邮件后,将邮件放入收信人的用户邮箱,等待收信人在方便时读取.
  • 收信人打算收信时,调用用户代理,使用POP3(或IMAP)协议将自己的邮件从接收方邮件服务器的用户邮箱中取回.

POP3 协议

• Post Office Protocol,邮局协议,采用Pull的方式, C/S工作模式，工作在110端口
• 两种工作模式: 下载删除,下载保留(保留副本在服务器)

IMAP协议

• 报文存取协议,提供了创建文件夹功能,维护了用户会话状态信息
• IMAP4协议的特性
• IMAP4协议的默认端口：143
• IMAP4协议默认传输协议：TCP/IP
• IMAP4协议适用的网络构架：C/S
• IMAP4协议访问模式：离线/在线
• IMAP4协议存储邮件模式：分布式
• RFC3501定义

6.5 万维网和HTTP协议

• World Wide Web, WWW, 是一个资料空间,这些资源通过URL标识，这些资源通过超文本传输协议(HTTP)传送给使用者,也可以单击访问获取资源.

• 由三部分组成:

  • URL: 负责标示各种文档,使得每个文档在万维网的范围内具有唯一的标示符URL
  • HTTP: 使用TCP进行可靠传输,是万维网客户程序和服务器程序之间交互所必须严格遵守的协议
  • HTML: 超文本白㷣集语言，一种文档结构的标记语言，它使用一些约定的标记对页面上的各种信息(包括文字，声音，图像，视频等)格式进行描述

• 定义了万维网客户进程(浏览器)怎样访问万维网服务器请求万维网文档,以及服务器怎样把文档传给浏览器,默认端口80

• HTTP的操作过程,以单击鼠标为例
  • 浏览器分析连接指向页面URL
  • 浏览器DNS请求解析URL中域名的IP地址
  • 域名系统DNS解析出服务器的地址
  • 浏览器与该服务器建立TCP连接(默认端口80)
  • 浏览器发出HTTP请求: GET /xxx/xxx.html
  • 服务器通过HTTP响应吧文件index.html发送给浏览器
  • TCP连接释放
  • 浏览器解析index.html,并将Web页显示给用户