【图解TCP/IP 归纳】第六章 TCP与UDP

第六章 TCP与UDP

6.1 传输层的作用

• 6.1.1 传输层定义

  • IP层负责将数据包从发送端传输到接收端，而传输层负责建立发送端与接收端的连接，并判断发送端的发送程序与接收端的接收程序（通过端口号）。在TCP层中，通常称为客户端和服务端

• 6.1.2 通信处理

  • （1）客户端为请求的发起端，服务端为请求的处理端；
    （2）服务端的程序有必要提前启动，一直监听客户端的请求，对于这样的服务端程序被称为守护进程。在实际情况中，是通过一直启动一个代表所有服务端接收客户端请求的超级守护进程inetd（互联网守护进程），该进程在接收到客户端请求后会复刻（fork）新的进程并转换（exec）为sshd等各个守护进程（通过端口号判断转换的进程）

• 6.1.3 两种传输层协议TCP和UDP

  • （1）TCP：是面向连接的，可靠的流协议。流就是指不间断的数据结构
  • （2）UDP：是不具有可靠性的数据报协议。细微的处理会交给上层去完成，其可以保证发送消息的大小，但不能确保消息一定会到达

• 6.1.4 TCP和UDP的区分

  • （1）TCP可靠性高但是实时性较差，主要用于有必要实现可靠传输的情况
  • （2）UDP主要用于那些对高速传输和实时性有较高要求的通信或广播通信
  • （3）使用TCP/UDP时会使用操作系统提供的类库，其被称为应用编程接口API。而使用TCP/UDP通信时，会广发使用套接字（socket）的API。应用程序可以直接通过利用套接字，可以设置对端的IP地址、端口号，并实现数据的发送与接收

6.2 端口号

• 6.2.1 端口号定义

  • 端口号识别同一台计算机中进行通信的不同应用程序

• 6.2.2 根据端口号识别应用

  • 通过数据中的端口号判断当前需要通信的程序

• 6.2.3 通过IP地址、端口号、协议号进行通信识别

  • 识别当前数据属于统一通讯—“源/目标IP地址”、“源/目标端口号”、"协议号"五个信息完全相同

• 6.2.4 端口号如何确定

  • （1）标准既定的端口号：静态方法，0—1023为知名端口号，1024—49151为正式注册的端口号
  • （2）时序分配法：时序分配法，服务端有必要确定监听的端口号，但是客户端的端口号可以完全交给操作系统按时序自动分配，在49151—65535之间

• 6.2.5 端口号和协议

  • 不同的传输协议可以使用相同的端口号，但是知名端口号与传输层协议无关，只要端口一致均分配给同一种程序处理

6.3 UDP

• （1）定义：User Datagram Protocol，利用IP提供面向无连接的通信服务，并且其是在应用程序发来数据的那一刻，则立即照原样发送到网络上的一种机制
• （2）特点：需要细节控制，则由其上层的应用程序去处理拥塞控制。处理简单高效，适合需要快速通信的地方

6.4 TCP

• TCP建立了“连接”，应用程序可以不用IP网络上的各种问题实现数据传输时的各种控制功能（连接的建立，断开，保持等管理工作）

• 6.4.1 TCP的特点及其目的
  

  • 通过校验和、序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现可靠性传输

• 6.4.2 通过序列号与确认应答提高可靠性

  • （1）确认应答：发送端与接收端在发送消息后，接收方收到后都需要发送一个确认应答ACK。其中发送的数据包与确认应答都带着序列号
  • （2）序列号：按照顺序给发送数据的每一个字节（8位字节）都标上号码的编号。其初始值时在建立连接以后自动生成的，并非是0

• 6.4.3 重发超时如何确定

  • （1）重发超时：在重发数据之前，等待确认应答到来的那个特定时间间隔
  • （2）确定方式：在每次发包前都会计算往返时间及其偏差，重发时间即这两个值的总和稍大一点。UNIX和Windows中超时都以0.5s为单位进行控制，因此超时和偏差都是0.5s的整数倍。每次重发，等待确认应答的时间会以2的指数倍增长，到达一定次数后连接强制关闭

• 6.4.4 连接管理

  • 即开始建立连接时的三次握手（SYN客户端请求连接连接—ACK+SYN服务端请求建立连接—ACK），以及断开连接时的四次挥手（FIN客户端请求切断连接—ACK—FIN服务端请求切断连接—ACK）；（具体参见单独的博文）

• 6.4.5 TCP以段为单位发送数据

  • MSS最大消息长度，为TCP连接中数据包的单位，在大量传输时会将数据根据MSS进行分割发送。其理想状况为MSS是IP中不会被分片处理的最大数据长度。其在三次握手阶段通过双方交流得到（段中的TCP首部包含MSS选项，选取双方中较小的值）

• 6.4.6 利用窗口控制提高速度
  

  • （1）原因：传统的1段1应答随着段的往返时间增加而效率变差
  • （2）滑动窗口实现：在窗口内的数据即便没有收到确认应答也可以被发送出去。不过在整个窗口的确认应答到达之前若出现丢包，那么发送端仍要负责重传。滑动窗口外的数据为未发送的数据/已经确认对端已收到的数据（滑动窗口在接收端和发送端均存在）

• 6.4.7 窗口控制与重发控制

  • （1）常规重发：内部某些端的确认应答丢失后，可以通过之后的确认应答来规避掉这些确认应答的重发
  • （2）高速重发机制：连续3次收到同一个确认应答，则将对应的数据进行重发（确认应答序列号+MSS长度的段）

• 6.4.8 流控制
  

  • （1）流控制：TCP提供的一种可以让发送端根据接收端的实际接收能力控制发送的数据量的机制
  • （2）控制流程：传递窗口大小。通过发送端时不时发送窗口探测包，接收端发送对应的窗口更新通知，来实现流量的传递控制过程（此时修改的是发送端的滑动窗口，即发送端的滑动窗口大小是随着接收端的滑动窗口更新通知而变的）

• 6.4.9 拥塞控制
  

  • （1）拥塞窗口慢启动控制：发送端定义了“拥塞窗口”的概念（以太网标准MSS值为1460字节），其每收到一次确认应答则增加其值（增加方式为先指数增长，在超过慢启动阈值值比例增长），然后与接收端通知的窗口大小作比较，最终使用两者中较小的值（发送端存在滑动端口进行流控制，拥塞端口进行拥塞控制；接收端存在滑动端口进行流控制）
  • （2）慢启动阈值后比例累积增长：（1个数据段的字节数/拥塞窗口（字节））× 1个数据段的字节数
  • （3）TCP的拥塞窗口变化分析：
    ① TCP开始正常通信时，并没有设置相应的慢启动阈值，其直接与窗口的最大值相同；
    ② 超时重发对于网路的负荷较大，当其触发时，慢启动阈值的大小设置为当前拥塞窗口大小的一半，而拥塞窗口直降低到初始值（即最小值）（根据发送端拥塞窗口与滑动窗口取最小值，所以此时直接变成最小值）；
    ③ 高速重发对于网络的负荷较小，当其触发时，慢启动阈值的大小设置为当前拥塞窗口大小的一半，而拥塞窗口的大小变为此时的慢启动阈值+3个数据段的大小（与超时重发后拥塞窗口直接初始化大小不同，高速重发后而保持了一定的吞吐量）；
    ④ 一般窗口越大，越会形成高吞吐量的通信；即TCP开始通信时会逐渐提升吞吐量，当出现拥堵情况时吞吐量会急速下降，再开始进入慢慢上升的过程。所以可以看做TCP通信是一种“有野心，但不自私”的通信；
    ⑤ 发送端的滑动窗口大小随着接收端的窗口更新通知（其常随着接收端缓冲区处理能力变化）而变化，发送端的拥塞窗口大小根据自己的增长情况以及超时处理等特殊处理机制而变化；接收端的滑动窗口大小随着自己缓冲区处理能力而自己变化

• 6.4.10 提高网络利用率的规范

  • （1）Nagle算法：如果发送端即使还有应该发送的数据，但如果这部分数据很少的话，则进行延迟发送
  • （2）延迟确认应答：为保证返回的窗口通知大小恰当，可以延时一段时间后再发送ACK（TCP文件传输中多为每两个数据段返回一次确认应答）
  • （3）捎带应答：指在同一个TCP包中即发送数据又发送确认应答的一种机制。其需要开启延迟确认应答，并需要等待到当前应用处理完数据并将作为回执的数据返回才行

6.5 其他传输层协议

• 6.5.1 UDP-Lite

  • 轻量级用户数据报协议，即修改计算校验和的范围，减少对于一些“错误”的包的丢弃率

• 6.5.2 SCTP

  • 流控制传输协议，特点为：以消息为单位；支持多重宿主即网卡；支持多数据流通信即单连接完成多通讯；自定义消息生存期限

• 6.5.3 DCCP

  • 数据报拥塞控制协议，一种面向连接的，用于辅助UDP进行断连连接，拥塞控制的协议

6.6 UDP首部的格式

• 由源端口号、目标端口号、包长度和校验和组成
• （1）源端口号（Source Port）：16bit的端口号，与IP地址不同，其常用整体数字大小表达；可以写为0，表示不需要返回
• （2）目标端口号（Destination Port）：16bit的端口号，与IP地址不同，其常用整体数字大小表达
• （3）包长度（Length）：16bit，UDP首部长度与数据长度之和
  
• （4）校验和（Checksum）：长16bit，通过UDP伪首部+UDP首部计算（上图为伪首部）
  计算方法：将UDP首部的校验和字段全部设为0，然后以16bit为单位进行1的补码和（即反码），并将所得到的1的补码和写入校验和字段（若计算出结果大于16bit，则将进位右移32位再加一次）；UDP的校验和设为0时可以不校验从而使传输速度更快

6.7 TCP首部格式

• TCP中没有表示包长度和数据长度的字段，则其包长度的计算公式为：TCP包长 = IP中获取的IP数据包长度 - IP首部长度 - TCP首部长度；TCP首部长由于附加项，最小为20字节，一般为4字节的整数倍
• （1）源端口号（Source Port）：长16bit，发送端的端口号
• （2）目标端口号（Destination Port）：长16bit，接收端的端口号
• （3）序列号（Sequence Number）：长32bit。初始值为每次建立连接时随机生成，每发送一次数据则累计一次该数据字节数的大小（SYN包、ACK包与FIN包虽然不携带数据但是都是加1字节）
• （4）确认应答号（Acknowledge Number）：长32bit，指下一次应该收到的数据的序列号。发送端收到此号时会认为在此序号之前的数据都已经被正常接收
• （5）数据偏移（Data Offset）：长4bit，表达单位为4Byte。表示TCP所传输的数据部分应从TCP包的哪个位开始算（也就是表明了TCP包的首部长度）
• （6）保留（Reserved）：长4bit，一般为0不处理，保留日后拓展使用
• （7）控制位（Control Flag）：长8bit，有8个控制位字符
  
  ① CWR：与ECE同用于IP首部的ECN字段，CWR为1时，则通知对方已将拥塞窗口缩小；
  ② ECE：为1时会通知对方，从对方到这边的网路存在拥挤。IP包中ECN的ECT和CE均为1时其为1；
  ③ URG：为1时表示包中有紧急处理的数据；
  ④ ACK：为1时表示此包为确认应答包；（规定除了初始的SYN包外该位均为1）
  ⑤ PSH：为1时表示需要将受到的数据立即传给上层应用，为0时为先缓存；
  ⑥ RST：为1时表示TCP连接中出现异常必须强行断开连接；
  ⑦ SYN：为1时表示希望建立连接，并在序列号字段处进行随机初始值生成，用于三次握手的交互
  ⑧ FIN：为1时表示确认今后不会再有数据发送，希望断开连接，用于四次挥手的交互
• （8）窗口大小（Window Size）：长16bit，通知从相同TCP首部的确认应答号所指位置开始能够接受的数据大小（滑动窗口），该数据为0时表示可以发送窗口探测，且必须是1字节以上
• （9）校验和（Checksum）：其不能像UDP一样全部设为0一样的关闭掉
  
  计算方法：同样使用伪首部，将校验和和填充位设为0，然后以16bit为单位进行1的补码的计算（若计算出结果大于16bit，则将进位右移32位再加一次），再将他们的总和的1的补码和放入校验和字段；（接收方按同样方式校验得到FFFF即OK）
• （10）紧急指针（Urgent Pointer）：长16bit，在URG = 1时有效，指向本报文段中紧急处理数据所处的位置（即数据部分的首位到指针所指位置为紧急数据）
• （11）选项（Options）：根据数据偏移进行控制，最大长度为40字节（数据偏移为4bit，单位为4Byte，所以TCP包首部最大长度为60Byte，首部固定长20Byte，所以选项最大为40Byte）；其中常用的有类型为2的决定MSS最大长度，类型为3的窗扩大选项，类型为8的时间戳选项，类型为4和5的选择确认应答选项（允许最大4次的缺参型确认应答数据报）
• （12）窗口大小与吞吐量：TCP通信的最大吞吐量由窗口大小（发送端滑动窗口）和往返时间决定。设最大吞吐量为T_max，窗口大小为W，往返时间时RTT，则最大吞吐量的公式为：T_max = W/RTT；按照首部中窗口大小的最大值65535字节，RTT为0.1秒计算，T_max = 5.242Mbps。如果采用多个连接则此数据为单个连接的最大吞吐量。所以使用多个TCP连接会达到更高的吞吐量（Web浏览器一般会同时建立4个左右的连接来提高吞吐量）

对应思维导图