【计算机网络】TCP协议

TCP协议段格式

• 源/目的端口号：表示数据是从哪个进城来，到哪个进城去；
• 4位TCP报文长度：表示该TCP头部有多少个32个bit；所以TCP头部最大长度时 15*4 = 60
• 6位标志位：
  • URG：紧急指针是否有效
  • ACK：确认号是否有效
  • PSH：提示接收端应用程序立刻从TCP缓冲区把数据读走
  • RST：对方要求重新建立连接；把携带RST标识的称为复位报文段
  • SYN：请求建立连接；把携带SYN标识的称为同步报文段
  • FIN：通知对方本端要关闭了；把携带FIN标识的称为结束报文段
• 16位校验和：发送端填充。接收端校验不通过，则认为数据有问题，此处的校验和不光包含TCP首部，也包含TCP数据部分
• 16位紧急指针：标识那部分数据时紧急数据

TCP的特点

• 有连接：传送数据之前必须建立连接，数据传送结束之后要释放连接
• 可靠：保证接收方进程从缓存区读出的字节流与发送方发出的字节流是完全一样的
• 面向字节流：可以控制读写数据的次数以及数量
  TCP的缓冲区
• 发送缓存
    准备发送的数据
    已经发送但尚未收到确认的数据
• 接收缓存
    按序到达但尚未被接收应用程序读取的数据
    不按序到达的数据

TCP的连接管理

建立连接————三次握手

1. 客户端发送连接请求报文段：
   客户端和服务器都处于CLOSED关闭状态，客户端将SYN置 1 并且随机产生一个seq为 X ；
   然后将数据包发送给服务器，客户端进入SYN-SENT状态等待服务器确认 （该过程不包含任何应用层数据）

2. 服务器允许连接为该TCP连接分配缓存和变量，并向客户端返回确认报文段：
   服务器收到数据包后由SYN=1得知客户端请求连接，服务器将标志位SYN和ACK都置为 1 ，ack=x+1并且随机产生一个值seq为 Y ，然后将该数据包发给客户端以确认连接请求，此时服务器进入SYN_RCVD状态并且为该TCP连接分配缓存和变量 （该过程不包含任何应用层数据）

3. 客户端为该TCP连接分配缓存和变量，并向服务器端返回确认的确认：
   客户端收到确认信息后，首先检查ACK是否为1且ack是否为x+1。如果都正确则将标志位ACK置为1，ack=y+1并且为该TCP连接分配TCP缓存和变量，然后将数据包发送给服务器，服务器收到后也检查ACK是否为1且ack是否为y+1，如果正确则成功建立连接。客户端和服务器都进入ESTABLISHED状态开始传输数据 （该过程可以包含应用层数据）

SYN洪范攻击

SYN洪泛攻击发生在OSI第四层，这种方式利用TCP协议的特性，就是三次握手。
攻击者发送TCP SYN, SYN是TCP三次握手中的第一个数据包， 而当服务器返回ACK后，该攻击者就不对其进行再确认，那这个TCP连接就处于挂起状态，也就是所谓的半连接状态，服务器收不到再确认的话，还会重复发送ACK给攻击者。
这样更加会浪费服务器的资源。攻击者就对服务器发送非常大量的这种TCP连接，由于每一个都没法完成三次握手，所以在服务器上，这些TCP连接会因为挂起状态而消耗CPU和内存，最后服务器可能死机，就无法为正常用户提供服务了。

释放连接——四次挥手

1. A发送连接释放报文段，停止发送数据，主动关闭TCP连接：
   A的应用程序先发出连接释放报文段（FIN=1,sqe=u）,并停止再发送数据主动关闭连接，进入FIN-WAIT-1状态等到B确认；

2. B会回送一个确认报文段，A这个方向的连接就释放了（半关闭状态）
   B收到连接释放报文段后立即发出确认报文段（ACK=1,ack=u+1，sqe=v），B进入CLOSE-WAIT(关闭等待状态)，此时的TCP连接处于半关闭状态（A到B的连接释放）

3. A收到B的确认后，进入FIN-WAIT-2（终止等待2）状态，等待B发出的连接释放报文段；

4. B发完数据，就发出连接释放报文段，主动关闭TCP连接：
   B没有要向A发送的数据了，B发出连接释放报文段（FIN=1,AKC=1,sqe=w，ack=u+1）,B进入LAST-ACK状态，等待A的确认；

5. A回复一个确认报文段，再等到2MSL（最长报文段寿命）后，连接彻底关闭：
   A收到B的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），A进入TIME-WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，A才进入CLOSED状态。

等待时间为何为 2MSL：

1.为了保证客户端发送的最后一个ACK报文段能够到达服务器。因为这个ACK有可能丢失，从而导致处在LAST-ACK状态的服务器收不到对FIN-ACK的确认报文。服务器会超时重传这个FIN-ACK，接着客户端再重传一次确认，重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待2MSL，而是在发送完ACK之后直接释放关闭，一但这个ACK丢失的话，服务器就无法正常的进入关闭连接状态。
2.它还可以防止已失效的报文段。客户端在发送最后一个ACK之后，再经过经过2MSL，就可以使本链接持续时间内所产生的所有报文段都从网络中消失。从而保证在关闭连接后不会有还在网络中滞留的报文段去骚扰服务器。

TCP关闭异常
正常四次挥手：

• 进程被关闭
• 机器被关机/重新启动

异常关闭：

• A突然断电并且无法恢复正常：

1. B是不会收到FIN通知的
2. 如果B准备发送数据，则要发送的数据一定不会被接收到且会触发超时重传，多次重传后B就会放弃并且会发送RST给对方（对方是否收到都无所谓），最后关闭连接 (这里关闭连接并不是正常的四次挥手)
3. 如果B此时正在读取数据，则B是无法知道任何事情的，阻塞在read上永远不会返回 （因为B无法区分A是死了，还是A没有说话）
   

• A突然断电然后又恢复正常：

4. 如果B是读取数据则和上面的过程一样；
5. 如果B是准备发送数据，数据会被正常交给A，不过此时A找不到相应的连接，会回复RST。B收到RST之后会正常的关闭B的连接，如果B还要进行通信则重新建立连接即可。

标志位 RST———Reset重置连接（用于连接异常）

• 接收数据时：

1. 根据数据中的五元组无法找到连接；
2. 找到连接的情况下，状态不正常；
3. 即使状态对，但***不在合法范围；

  以上情况下就会给对方发送RST，同时伴随着自己这边的TCP连接的关闭（异常关闭）

• 如果收到RST时

1. RST不需要应答；
2. 伴随着自己这边的TCP连接的关闭（异常关闭）

TCP的可靠传输

确认应答机制————通过***与确认应答提高可靠性

***：就是按顺序给发送的数据每一个字节都标上号码。
接收端通过查询接收数据TCP首部中的***和数据的长度，将自己下一步应该接收的序号作为确认应答返送回去。就这样通过***和确认应答号，TCP可以实现可靠传输

超时重传机制
A给B发送数据后如果在一段时间内没有收到B的回复，则认为B没有收到就会触发超时重传

• B没有收到数据包的情况：
  
• A没有收到B的确认应答数据包的情况：
  
• 重发超时的时间如何确定

超时时间一般都以 0.5 秒为单位进行控制，因此重发超时都是 0.5 秒的整数倍。不过由于最初的数据包还不知道往返的时间，所以首次一般都设置为 6 秒左右
数据重发后若还是收不到确认应答，则会进行再次发送。此时等待确认应答时间将会2倍、4倍的指数增长
不过数据不会被无限制的反复的重复大，当重发达到一定的次数时如果还是收不到应答则会强制关闭连接（异常关闭）

滑动窗口机制———利用窗口控制来提高速度

• MSS——最大消息长度
  TCP在传送大量数据时，是以MSS的大小将数据进行分割发送的。MSS是在三次握手时被确定的，两端的主机在发出建立连接的请求时，会在TCP首部中写入MSS选项，告诉对方自己的接口能够适应的MSS的大小，最后会在两个值中取一个较小的值投入使用。
  
• 滑动窗口
  TCP以1个段位单位，每发送一个段就进行一次确认应答的处理，然后才可以继续进行发送。
  
  这种模式效率很低,为了解决该问题TCP采用滑动窗口机制一次发送多条数据，将多个段的等待时间重叠在一起来提高性能
  

1. 发送端在发送了一个段以后不必要一直等待确认应答，而是继续发送；
2. 窗口的大小就是指无需等待确认应答而可以继续发送数据的最大值；
3. 这个机制实现是使用了大量的缓冲区，通过对多个段同时进行确认应答的功能；
   

• 窗口控制以及重发控制
  当某一段数据丢失后，也会触发重传机制：
  

流量控制机制
  接收端处理数据的速度有限，如果发送端发送数据太快，导致接收缓冲区满了，如果发送端再进行  发送数据，就会造成丢包
  所以TCP支持根据接收端的处理能力来决定发送端的发送速度，也就是流量控制

• 接收端将自己的缓冲区大小放入TCP首部中的“窗口大小”字段，通过ACK告诉发送端；
• 窗口越大，说明网络的吞吐量越高
• 接收端发现自己的缓冲区快满的时候，就会减小窗口的大小，当发送端接收到这个消息后也会降低自己的发送速度
• 当接收端的缓冲区满了之后，接收端会将窗口大小设置为0，这时发送端就不会再发送数据了，但是它会定期发送一个窗口探测数据段来获取接收端的窗口大小
  

拥塞控制机制
同一时间可能有多人上网，造成网络拥堵，如果此时滑动窗口在开始阶段就发送大量的数据同样有可能出现问题
TCP引入慢启动机制，先发少量的数据，探探路，摸清网络当前的拥堵状态，再决定按照多大的速度传输，此时就引入了拥塞窗口这个概念

• 刚开始将拥塞窗口置为1
• 每接收到一个ACK，拥塞窗口加1
• 每次发送数据时，将拥塞窗口与接收端反馈的缓冲区窗口作比较，选择较小的窗口传输
• 拥塞窗口的增长是指数级增长，为了不让增长的太快，引入一个慢启动的阈值
• 当拥塞窗口按指数级增长超过阈值时，就以线性方式增长
• 当TCP开始启动的时候，慢启动阈值等于窗口最大值
• 在每次超时重发的时候，阈值会变成原来的一半，拥塞窗口重新置为1
  
  

少量的丢包, 我们仅仅是触发超时重传; 大量的丢包, 我们就认为网络拥塞;
当TCP通信开始后, 网络吞吐量会逐渐上升; 随着网络发生拥堵, 吞吐量会立刻下降;
拥塞控制归根结底是想尽可能快的把数据发送给对方，但又避免造成网络拥堵

延迟应答机制
如果接收数据的主机立刻返回ACK应答，这时候返回的窗口可能比较小

窗口越大，网络的吞吐量就越大秘传书的效率就越高。

但是也并不是所有的包都需要延时应答，一般每隔2个包就应答一次，超过最大延迟时间就应答一次（一般取200ms）

捎带应答机制
在延迟应答的基础上, 我们发现, 很多情况下, 客户端服务器在应用层也是 “一发一收” 的. 意味着客户端给服务器说了"How are you", 服务器也会给客户端回一个 “Fine, thank you”;
那么这个时候ACK就可以搭顺风车, 和服务器回应的 “Fine, thank you” 一起回给客户端

基于TCCP应用层协议

• HTTP
• HTTPS
• SSH
• Telnet
• FTP
• SMTP

TCP小结
可靠性：

• 校验和
• ***
• 确认应答机制
• 超时重发机制
• 连接管理
• 流量控制
• 拥塞控制

提高性能

• 滑动窗口哦
• 快速重传
• 延迟应答
• 捎带应答