TCP/IP五层模型——传输层协议(TCP/UDP协议)

传输层协议负责应用程序之间的数据传输。比较知名的应用层协议有：UDP协议、TCP协议

UDP协议

UDP协议特性：无连接，不可靠，面向数据报

• 无连接：通信的时候，不需要建立连接，只需要知道对方地址信息，就可以直接发送数据
• 不可靠：通信过程中，不保证数据安全可靠、有序地到达对端
• 面向数据报：限制最大传输大小的一种传输方式

udp报文组成：协议头信息(源端口、目的端口、数据报长度、校验和)+数据

• 16位源端口/16位目的端口：描述数据从哪个进程发送到哪个进程，负责实现应用程序间的数据传输
• 16位数据报长度：包含udp报文头部在内的整体报文长度，存储的最大数字是65535，因此一个完整的udp报文长度应该小于64k
• 16位校验和：二进制反码求和算法，用于校验接收到的数据和发送的数据是否一致

udp协议特性和报文组成对上层应用的影响：

• 若sendto传输的数据(应用层的原始数据)大小大于64k-8 (udp报文头部长度是8个字节)，则传输会因数据过大而报错。因此若数据过长，需要程序员在应用层进行分包操作，将大数据分割成一个个小的数据段(不大于64k-8)进行sendto逐个发送
• 因为udp并不保证数据有序到达，程序员进行数据分包之后，就要考虑在应用层实现各个数据段的包序管理
• udp报文头部定义了数据报长度，报文是整条收发的，因此udp在使用recvfrom获取数据的时候，定义的接收buffer要足够大，防止出现数据过长给的buffer不够而报错，接收失败的情况

TCP协议

TCP协议实现：

• 16位源端口/16位目的端口:负责应用程序之间的数据传输
• 32位序号/32位确认序号:实现确认应答机制，以及进行包序管理
  • 确认序号的功能：告诉发送方，这个确认序号以前的数据都已经收到了；如果第一条数据丢失, 就算收到第二条，也不会进行回复，因为每一条回复表示的都是前边的数据都已经完全收到了。这种方式可以避免因为ack确认回复的丢失而导致的重传；对发送方来说收到1025，表示1~ 1024成功传输;收到2049,表示1~ 2048成功传输
• 4位头部长度:表示tcp头部有多长
  • tcp头部是不定长数据，主要取决于选项数据的大小，tcp头部最小20字节，4位2进制位能表示的最大数字为15，所以以4字节为单位，最大60字节(其中选项数据占0~40字节)
• 6位保留位:现在没想好要用来干什么,先预留着用于以后扩展
• 6位标志位: URG/ ACK/ PSH/RST / SYN / FIN
• 16位窗口大小:用于实现滑动窗口机制,进行流量控制
• 16位校验和:二进制反码求和算法,校验数据接收与发送的一致性
  • 校验和的功能：校验数据是否一致，不一致则要求对方进行重传；哪一条数据不一致,则回复这条数据的起始序号；比如1~ 1024的数据不一致，就会回复确认序号1,要求对方重传1起始的数据
• 16位紧急指针:标识哪些数据是紧急数据(带外数据)
• 0~40字节的选项数据:通常用于协商一些信息
  标志位标志含义：

  标志	含义
  URG	紧急指针标志位(标志紧急指针是否有效)
  ACK	确认回复标志位(标志确认号是否有效)
  PSH	提示接收端立即从缓冲区拿走数据
  RST	提示接收端重新发起连接
  SYN	建立连接请求
  FIN	断开连接请求

TCP协议特性:面向连接、可靠传输、面向字节流

面向连接：保证连接连接建立成功之后再发送数据

TCP连接管理中的保活机制: TCP协议是面向连接通信，若通信双方长时间没有数据往来,就需要确定对方还是否在线,连接是否正常?

• 若通信双方长时间(7200秒)没有数据往来，则服务端每隔一段时间(75秒)会向客户端发送一个保活探测数据包， 要求对方进行响应,若多次(9次)无响应,则认为连接断开
• 可以通过设置套接字选项setsockopt进行手动配置等待时间、发送探测数据包的间隔时间、响应次数
• 连接断开对上层程序编写的影响：接收不到----recv返回0/无法发送----send触发异常

TCP连接建立过程：

TCP连接断开过程：

可靠传输：保证数据能够安全有序到达对端，只要不是网络断开一定保证数据到达对端

面向字节流:流式传输，根据实际情况选择合适大小的数据进行传输

• 数据可以在发送缓冲区或接收缓冲区中进行堆积缓冲，减少IO次数提高了效率
  • 发送缓冲区中有很多数据，tcp就会根据mss取出合适大小的数据进行传输
  • 接收缓冲区中有很多数据，tcp也可以灵活的以用户需要的大小向上交付
• 但这种数据在缓冲区中堆积会带来一个问题: tcp粘包(将多条数据当作一条数据进行处理)
• 粘包的本质原因: tcp在传输层对数据边界不敏感(不关注上层数据是什么样，每次都根据mss取出合适大小进行发送，不管接收缓冲区中是什么数据，只管从缓冲区中取出用户需要的大小的数据进行交付)，因此造成了粘包问题
• 粘包的解决方案:程序员在应用层进行数据的边界管理
  • 使用特殊字符进行间隔：每条数据结尾有个特殊字符,数据中的特殊字符需要进行转义
  • 数据定长：每次只发送/接收指定长度的数据，数据短了会造成资源浪费
  • 在应用层头部中定义数据长度字段：先按照指定长度将头部获取，根据头部中的长度,取出指定长度数据
  • 典型的例子: http先用特殊字符间隔头部，在头部中定义正文长度；udp使用数据定长的方式，在头部中定义数据长度

TCP协议的特殊机制

TCP协议的特殊机制按功能可分为三类：

• 可靠传输的实现:面向连接、确认应答机制(序号/确认序号)、超时重传机制、校验和
• 避免丢包:滑动窗口机制、拥塞控制机制
• 提高性能:快速重传机制、延迟应答机制、捎带应答机制

确认应答机制：对于发送的每一条数据，都要求对方进行确认回复

• 协议字段中的序号和确认序号：实现确认应答机制，并进行包序管理

超时重传机制：在指定时间内没有收到确认回复，则认为数据丢失，对之前的数据进行重传

滑动窗口机制:实现数据的连续发送、进行流量控制、避免发送数据过多来不及接收导致的丟包

• 滑动窗口机制通过协议字段中的窗口大小实现。通过窗口大小告诉对方最多发送多少数据，避免因为发送数据过多，接收缓冲区满溢导致的丢包
• 在三次握手的时候，通信双方会通过选项数据协商一个信息: MSS(最大数据段大小，即应用层的原始数据大小)
• tcp发送数据的时候，会从发送缓冲区中取出不大于MSS大小的数据封装tcp头部进行发送
• 窗口大小通常不大于接收方接收缓冲区中剩余空间大小(窗口前沿的序号减去窗口后沿的序号,大小不能大于对方发送的窗口大小)
• 发送窗口:前沿减去后沿就是接收方告知的窗口大小
  • 后沿:发送数据的起始序号—后沿的移动取决于是否收到了确认回复
  • 前沿:能够发送的数据的结束序号—前沿的移动取决于接收方告知的窗口大小
• 接收窗口:前沿减去后沿不大于接收缓冲区中剩余空间大小
  • 后沿:接收数据的起始序号—后沿移动取决于是否收到的起始序号的数据
  • 前沿:接收数据的结束序号—前沿移动取决于缓冲区中剩余空间大小(改变:数据被取出/缓冲区重新调整大小)

拥塞控制机制:发送数据时，一开始在网络状况不明的情况下， 滑动窗口一次连续发送多条数据，有可能会造成因为网络状况不好导致发的越多，丢的越多。因此因该在发送数据时，进行网络探测，查看网络是否能够支持数据的连续快速传输

• 实现原理:慢启动,快增长；根据网络状况决定发送数据的快慢

快速重传机制:提高重传效率

• 发送方连续发送多条数据时,若接收方首先接收到了后边数据，则有理由认为前边的数据有可能丢失；此时开始向发送端连续发送三条前边丢失数据的重传请求,发送方接收到连续三次重传请求，则会对这条数据进行重传
• 为什么三次:有可能前边的数据只是延迟了，而并非丢失了，三条重传请求之间就可以有一个缓冲时间，这个时间内若收到了前边的数据， 三次重传请求没有发送完，则发送端就可以不用重传了。
• 重传的三种协议:停等协议、选择重传协议、回退n步协议
  • 停等协议:收到一条回复才会发送第二条数据—适用于网络状况特别差的场景
  • 回退n步协议:从丢失的数据开始，往后的数据都需要重传一-遍
  • 选择重传协议:哪条丢了，就重传哪条

延迟应答机制:接收方若接收到数据之后立即回复，则窗口大小会变小，传输吞吐率就会降低

• 接收方使用延迟应答机制，延迟一段时间再进行确认回复(在延迟的这段时间内，有可能数据就会被用户取出),保证传输吞吐率

捎带应答机制:每一条确认回复, 都是一个确认回复序号；为了确认回复,必须组织一个tcp数据包发送给对端， 会造成大量空包的发送

• 若接受方即将发送一条数据给对端， 则可以在这条即将发送的数据包头中对上一条数据进行确认回复, 节省一个空报头的传输