Tcp协议

Tcp协议段格式

 

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

Tcp的重要机制

1.确认应答机制（保障可靠性）

Tcp的核心就是可靠性，可靠性的核心保障就是确认应答机制。

    从这个图中就可以很清楚的看到，第一个请求，A给B发了1000个字节的数据，序号就是1—1000，这个操作就相当于是发了一个Tcp数据报，这个数据报的序号位1，长度位1000。确认应答这个数据报的确认序号就是1001。这个1001的意思是1001之前的数据我已经收到了，也可以理解为向A在索要1001开始的数据。发送方就可以根据返回的报文来知道是否收到。

2.超时重传机制（保障可靠性）

在确认应答机制下还是比较安全的，但是在传输过程下可能会发生丢包这种情况。

这种情况一般会有两种1、A发了一条消息B压根就没收到

                                     2、B收到了消息，并返回了确认的报文，但是A没收到报文

发送方是不知道发生了哪种情况，它只能做的是隔一段时间进行重新发送。如果它又发了一条，还是没有什么响应，它就会隔更长一段时间进行重发，这样三次后还没有成功就基本认定这个传输就不同了。

我们可以假设一下丢包率为10%（比较高了），我们三次的丢包率就为0.1%，那么这么低的概率基本不会出现误判。

如果我们假设是第二种情况，我们就会发很多份相同的报文给B，那么这些数据重复了怎么办。接收方会把数据先放到数据缓冲区中，这个数据缓冲区是一段内存，每个socket都有，在这里面会按报文序号进行去重。此时读到的数据就不是重复的了。

3.连接管理

Tcp三次握手

三次握手中服务器是被动的一方，主要目的是确实A，B之间的通信是否流畅，另一个就是通通气，比如确定TCP的序号是从几开始的。

 这个就是三次握手的过程。那这syn和ack是什么呢？SYN为同步报文段，ACK为确认报文段，他们都是Tcp报头中的6位标志位中的其中一个。

 它这个过程就可以理解为你和朋友连麦打游戏，开始肯定要确认通信是否正常。你会说一句能听见吗（SYN），你朋友会回一句可以听到（ack）+你呢（SYN）（在这块就知道你的发送信息能力正常，你朋友的接收信息能力正常），你说一句可以听见（ack）（在这里就可以确定你的接受能力正常，你朋友的发送能力正常），这下你们就会知道麦是正常的。这就可以可以类比一下三次握手。

比较重要的状态

 常见的问题

可以两次握手吗？

不行，两次握手就等于你和你朋友连麦，你问了，你朋友答了，反问你，结果你没反应。这时候就能确认你的接收能力和你朋友的发送能力是否正常。

可以四次握手吗？

可以，四次握手就是把中间的ack和syn分开，这样是可以的，只要确保你们的发送和接收能力正常就行。

Tcp的四次挥手

 这个就是Tcp四次挥手的过程，FIN为结束报文段，ACK为确认报文段，这个过程可以把A,B类比为男女朋友，A先提分手B说知道了，让我考虑考虑，然后过段时间给A说那就分手，A说好。这就是一次完整的四次挥手的过程。

常见问题：B发出的ACK和FIN可以合并吗？

不行，发出ACK是因为收到A发出的FIN，而发出FIN是用户代码进行确定的，当代码中出现socket.close后才会触发FIN。

FIN的触发表面上看是socket.close，实质上是操作系统内核中的释放了对应PCB的文件描述符。比如代码中没有调用close，但是进程结束了，PCB被销毁了，PCB上的文件描述符也就没有了，同样也会触发FIN。

四次挥手一定会执行吗？

不一定，它是一个正常的退出程序，但是也有异常的时候，比如网线断了。

4.滑动窗口

处理传输效率的问题

5.流量控制

     目的：此处的流量控制是对滑动窗口的进一步补充，它是基于接收方的处理能力来限制窗口的大小的，用来保证可靠性。

        窗口的大小界定了传输的效率，窗口越大效率就越高。既然如此多大合适呢。此处的流量控制就是基于接收方的处理能力来限制窗口大小的，Tcp这个传输数据的过程，就可以类似一个生产者消费者模型。

6.拥塞控制

拥塞控制时站在另一个角度来限制窗口的大小的，流量控制是看接收方的处理能力而拥塞控制是看中间的链路的畅通能力如何，它是一个逐渐尝试的过程，如图所示，先从0开始，进行指数增长当到了一个阈值进行线性增长，当遇到阻塞时归零，然后阈值进行减小。然后再重复前面的操作。

当每次Tcp启动时，阈值等于窗口最大值。

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

真实的发送窗口大小=min(流量控制窗口，拥塞控制窗口)。

7.延迟应答 

延迟应答的目的是提高效率，延迟控制这个机制也可以看作为一个窗口，不过这个窗口是接收方的缓冲区剩余的空间的大小，我们会尽可能的等这个窗口变大然后再返回带有窗口大小的ACK。

8.捎带应答

捎带应答的目的也是为了保证TCP的效率问题。因为网络通信涉及到了大量的封装和分用的过程，这个过程是针对每一个包的。所以当我们减少包的时候就可以提高效率了。

由于有延迟应答机制，返回的ACK不会立即返回而是需要等一会，所以在这个等待的时间里服务器可以返回业务上的response，他就可以和ACK一块进行返回回来了。

9.面向字节流（粘包问题）

原因：应用程序从缓冲区读取到的数据不知道从哪读到哪，就会发生多读或者少读的问题

这个问题不是TCP一个有这个问题，而是只要用字节流进行传输的协议都有这个问题

解决方案：1.设定结束符，约定每一个数据报以；结束。

                   2.设定包的长度：约定每个应用层数据报的前4个字节为存储数据报的长度。

10、TCP中的一些异常情况（心跳机制）