TCP协议--确认应答，超时重传，连接管理，滑动窗口，流量控制，拥塞控制，延时应答，捎带应答，面向字节流，粘包问题

TCP协议：

面向连接，可靠传输，面向字节流
连接管理：

• 服务端：

  1. 创建套接字
     

  2. 为套接字绑定地址信息
     

  3. 开始监听（可以接受客户端的请求，并完成三次握手）
     

• 客户端：

  1. 创建套接字
     

  2. 为套接字绑定地址信息
     

  3. 向服务端发起连接请求（三次握手（操作系统内部完成）：客户端发送SYN，服务端发送ACK+SYN，客户端发送ACK）
     

• 三次握手：两次不安全，四次没必要。挥手三次是为了保证数据收发的正确性：缺乏状态保护的情况下，收到一个SYN就会建立一个新的socket，完整的状态保护避免对一个客户端创建多个socket，SYN有时会因为网络延迟推迟，有时可能第一个SYN传输过去，而客户端已经关闭了，呢SYN就占用了资源；如果只有两次握手的话，服务端无法通过客户端的SYN确定客户端有数据收发的能力，需要再次进行SYN确认。

• 三次握手失败：服务端超时等待ack之后，向客户端发生rst报文，然后释放新建的socket资源。

• 主动关闭方TIME_WAIT状态的作用：

  • 假设没有TIME_WAIT而是直接进入closed状态会造成什么危害：在主动关闭方发送的最后一次ack丢失的情况下，1.如果主动关闭方使用相同的地址信息立即重启，收到被动关闭方超时等待后重启的fin包，请求会对新连接造成影响。2.发送SYN请求，但是对方等待的是ACK，因为状态不对导致对新连接造成影响，因此主动关闭方需要等待一段时间：2个MSL时间；若是对方重新发送fin请求，可以对其再次进行确认回复。

    • MSL:报文最大生命周期（30秒）
    • 等待两个MSL是为了让网络中延迟的报文（后续重传的fin和ack）都消失在网络中，不会对后续造成影响

  • 大量TIME_WAIT解决方案：调整msl时间，设置套接字选项（地址复用）

• 四次挥手：被动关闭方，收到fin之后对其进行ack回复，但是不能直接关闭socket，因为这时候用户可能正在处理数据，（socket接收缓冲区中有可能还有堆积的数据），需要用户来确认什么时候关闭socket发生fin，因此ack和fin不能放一块。

• TCP的可靠传输：面向连接，为了保证可靠传输，牺牲了部分性能（有些性能的损失是没必要的：ack丢失导致的重传）

  • 确认应答机制：对每一条数据，向发送方进行确认回复；
  • 超时重传机制：发送数据后等待一段时间（200ms）若是没有收到确认回复，则认为数据丢失，进行重传。
  • 协议字段中的：序号+确认序号（保证数据有序的向应用层交付）
  • 协议字段中的：校验和（校验接收的数据与发送的数据是否一致，不一致则发送重传请求，否则确认回复）

• TCP又采用了几种机制来避免无谓的性能损失以及提高性能的方法：

  • 滑动窗口机制：mss：最大报文大小

    • 流量控制：通过协议字段中窗口大小（不会大于接收法接收缓冲区剩余空间大小）字段，控制发送方发送数据大小，避免因为发送过快而接收方数据处理过慢导致接收缓冲区数据放满后，大量的数据丢失重传降低的性能。窗口大小在每次对数据进行确认回复的时候都会进行重新协商。

    • 每一条确认回复中的确认序号都要保证之前的数据已经完全收到了，或者没有收到第一条回复，但是收到了第二条回复，认为第一条和第二条都已经正确传输，避免了因为ack丢失导致的数据重传。

    • 快速重传机制：接收方收到了第二条数据但是没有收到第一条，则初步认为第一条数据丢失，则立即发送第一条数据的重传请求，并且连续发送三次，当发送方连续接收到三次重传请求时，不需要等待超时，直接对这条数据重传，避免因为网络阻塞，数据延迟到达而导致的重传。

    • 拥塞控制：在网路通信开始时，并不会直接发送窗口大小的数据，而是以一种慢启动，快增长的形式进行数据传输，起到一个网络探测的作用，避免开始通信时因网络状况不好导致的发送数据越多，丢失数据越多的重传性能损耗，在快增长过程中，若出现丢包则初始化拥塞窗口大小，重新开始探测网络状态

• 延迟应答机制：接收方接收数据若是立即回复，则窗口大小会降低，会导致传输速度降低，因此接收方接收到数据后，并不立即回复，而延迟一会（不超过500ms），在这期间，用户可能将数据从接收缓冲区中取出，可以尽最大的能力保证窗口大小，保证传输速度不会降低。

• 捎带应答机制：每次接收方对发送的数据进行确认回复，若是单独发送一个数据报（仅仅包含一个tcp报头）是不划算的，解决方法就是将要进行的确认回复和即将要发送的数据合到一起进行发送，就可省略一个tcp报头的发送，减少网络中不必要的流量信息；

• tcp的可靠传输：

  • 连接管理，确认应答，超时重传，序号/确认序号，校验和
  • 滑动窗口机制（流量控制，拥塞控制，快速重传），延迟应答，捎带应答

• 面向字节流：数据不会直接发送，而是放在缓冲区中，操作系统选择一个合适的时机将合适大小的数据以字节流的形式发送出去。对方接受数据时可以一次性接受所有数据，也可以分多次接受。

  • tcp面向字节流特性：传输灵活，但是会造成粘包问题
    • tcp传输的数据在发送缓冲区或者接受缓冲区中堆积，因为tcp数据收发的灵活性，导致有可能多条数据当做一条接受；（两条数据的粘连），
    • tcp粘包的本质原因：tcp在传输层，对数据的格式并不关心，对数据之间没有边界区分，因此造成的数据粘包；粘包是tcp在传输层对数据边界不敏感，因此需要用户在应用层进行数据边界管理：
      • 特殊字符间隔（&）。
      • 数据定长
      • 不定长数据：在应用协议头中声明数据长度。

• tcp连接管理中的保活制：若是通信双方，长时间（7200ms）没有数据往来，在会向对方发送保活探测数据包（要求对方对这个数据包进行回复），若是收到回复则认为连接正常，若是间隔（75s)发送连续多次（9次）没有收到回复，则认为连接断开。

  • tcp异常连接断开的情况：断电

• TCP协议字段：

  • 16位源/目的端口：负责端与端之间的数据传输
  • 32位序号/确认序号：保证数据有序交付
  • 4位头部长度：解析时tcp头部，以4字节为单位（tcp头部最小20字节，最大60字节）
  • 6位标志位：URG/ACK/PSH/RST/SYN/FIN
  • 16位窗口大小：实现滑动窗口，以及进行流量控制
  • 16位校验和：保证数据一致性
  • 16位紧急指针：标识那个数据是紧急数据