网络原理知识总结2——TCP协议_tcp一直不关闭csdn

目录

一、tcp协议主要段格式

二、核心机制

1.确认应答

2.超时重传

3.连接管理

（1）三次握手

（2）四次挥手

（3）核心状态

4.滑动窗口

5.流量控制

6.拥塞控制

7.延迟应答

8.捎带应答

       粘包问题

        TCP对于异常情况的处理

9.基于TCP应用层协议

---

一、tcp协议主要段格式

1. 4位首部长度：描述应用层数据从哪里开始（4个字节）
2. 源端口号：表示数据从哪个进程来
3. 目的端口号：表示数据到哪个进程去
4. 32位序号
5. 32位确认号
6. URG：紧急指针是否有效
7. ACK：确认号是否有效
8. PSH：提示接收端应用程序立刻从TCP缓冲区把数据读走
9. RST：要求对方重新建立连接，称为“复位报文段”
10. SYN：请求建立连接，称为“同步报文段”
11. FIN：通知对方本端关闭，称为“结束报文段”
12. 16位校验和：发送端填充，CRC校验，接收端校验不通过，则认为数据有问题

二、核心机制

1.确认应答

         保证TCP可靠性的核心机制，确认序号在TCP中表示接下来想要的编号，应答报文ACK

2.超时重传

         可靠性体现，针对丢包情况进行数据重传。针对丢包情况分为以下两种

1. 主机 A 发送数据给主机 B 后，可能因为网络拥堵等原因，数据无法到达主机 B 。如果主机A在一个特定的时间间隔内没有收到 B 发来的确认应答，就会进行重发。
2. 主机 A 成功发送数据，但是丢失主机 B 的确认应答。因此主机 B 会收到很多重复数据，那么 TCP 协议需要能够识别出哪些包是重复的，并把重复的丢弃（使用确认号去重）。 

         TCP 为了保证无论在任何环境下都能比较高性能的通信，因此会动态计算这个最大超时时间。例如：

• 超时时间以 500 ms为一个单位进行控制，每次判定超市重发时间都是 500 ms的整数倍；
• 如果重发一次以后，仍然得不到应答，等待 2*500 ms后再进行重传；
• 如果仍然得不到应答，等待 4*200 ms进行重传，以此类推，以指数形式递增；
• 累积到一定的重传次数， TCP 认为网络或者对端主机出现异常，强制关闭连接

3.连接管理

（1）三次握手

           本质是确认通信双方发送能力和接收能力都正常。

1.  主机 A 给主机 B 发送 SYN 后，主机 B 得知主机 A 的发送能力正常，自己的接收能力正常；
2. 主机 B 给主机 A 发送 ACK + SYN ，主机 A 收到后，得知主机 B 的发送能力正常，同时间接得知自己的发送能力正常，主机 B 的接收能力正常；
3. 主机 A 给主机 B 返回 ACK ，主机 B 确认自己的接收能力正常，同时间接确认自己的发送能力正常。

         因此经过三次握手通信，主机 A 和 B 对自己和对方的发送接收能力进行了验证，确保了通信的进行。

         三次握手可将第二次拓展为两次发送数据，成为四次握手，但是此做法会降低通信效率；不可变成两次握手，因为这样无法验证通信双方的发送和接受能力。

（2）四次挥手

        主机A 给主机B 发送结束报文，主机B 返回确认ACK ，主机B 返回FIN ，主机A 返回ACK ，至此通信双方都关闭了通信。 

        四次挥手的第二、三步不一定能合并。因为发送ACK是操作系统内核的行为，收到FIN的第一时间回复ACK；发送FIN是应用程序的行为，代码执行close（）。

（3）核心状态

1. ESTABLISHED： 连接成功，可以进行后续通信；
2. LISTEN：服务器端进入的状态，服务器准备就绪，允许客户端连接；
3. CLOSE_WAIT：中间状态，断开连接的中间状态（存在时间较短），出现收到FIN，返回ACK，到发送FIN这个间隙，一般出现这个状态表明程序出现BUG；
4. TIME_WAIT：断开连接时的状态，谁主动断开连接，谁进入状态，为了防止最后一个ACK丢包做准备，对方没有重传FIN，就视为最后一个ACK没丢包，真正释放连接。TIME_WAIT等待的时间为 2MSL，MSL表示网络中两个主机之间传输数据的最大时间间隔。

4.滑动窗口

1. 重传机制（确认号的设计）：超时重传+滑动窗口 ==> 快速重传（只传缺少的部分）
2. 窗口大小限制因素：传输效率、内存消耗、接收方的处理效率（从队列中取得速度）

         窗口大小指的是无需等待确认应答而可以继续发送数据的最大值，发送前几个段的时候，不需要等待任何ACK，直接发送；收到第一个ACK后，滑动窗口醒后移动，继续发送下一个段的数据。操作系统内核为了维护这个滑动窗口，需要开辟发送缓冲区来记录当前还有哪些数据没有应答，只有却应答过的数据，才能从缓冲区删掉，窗口越大，网络吞吐率越高。

         丢包进行重传的情况:

1. 数据包已经抵达，ACK被丢了。可以通过后续的ACK进行确认；
2. 数据包丢了，使用 “快重传”。

5.流量控制

1. ACK中：确认序号+接收方缓冲区的剩余空间的大小
2. 过了重发超时的时间，没有收到窗口更新的通知，发送方进行窗口探测
3. 根据TCP报头中的 “16位窗口大小” 字段，发送方确认窗口大小

        此方法是接收方根据自己的处理能力，反向控制发送方的发送速率。

6.拥塞控制

        发送方采取动态变化的过程，试探窗口的大小。

        慢开始：发送方在初始情况下，设置比较小的窗口大小，尝试更大窗口，直至丢包缩小窗口，循环反复。

7.延迟应答

        当主机B收到主机A的数据后，并不是立刻返回ACK，而是等待500ms，则ACK返回更大窗口（可能应用程序从缓冲区取走了数据）

8.捎带应答

        应用程序返回响应时，顺带携带ACK数据，减少了传输的数据包的个数，降低了通信成本，提高了效应。

       粘包问题

                面向字节流的问题

                应用层在缓冲区中无法区分完整的数据报

                解决：设计应用层协议时，能够显示的区分出来数据报的边界

                          1.显示的指定包的长度

                          2.显示的指定包和包之间的分隔符（结束标记）

        TCP对于异常情况的处理

1. 进程终止：进程终止会释放文件描述符，仍可以发送FIN，和正常关闭没有区别，会导致四次挥手；
2. 机器重启：按正常流程重启，系统会杀死进程，触发四次挥手。主机B会以LAST_ACK状态重传几次FIN，一直没有ACK之后会释放连接
3. 机器掉电/网线断开：A与B进行通信时，A断开通信

                       （1）主机B 是发送方：对方没有ACK，触发 “超时重传” 达到一定次数会重置连接（复位报文段RST）

                       （2）主机B 是接收方：TCP协议中内置了 “保活机制” ==> “心跳包”.每隔一段时间，B会给A发送一个很短的报文（PING），期待   对方返回一个回应（PONG）

9.基于TCP应用层协议

• HTTP
• HTTPS
• SSH
• Telnet
• FTP
• SMTP
• 自定义的TCP程序应用层协议