目录
1.TCP协议的段格式
2.TCP原理
2.1确认应答
2.2超时重传
3.三次握手(重点)
1.TCP协议的段格式
我们先来观察一下TCP协议的段格式图解:
源/目的端口号:标识数据从哪个进程来,到哪个进程去
32位序号/32位确认号:TCP会话的每一端都包含一个32位（bit）的序列号，该序列号被用来跟踪该端发送的数据量。每一个包中都包含序列号，在接收端则通过确认号用来通知发送端数据成功接收
4位TCP报头长度:表示该TCP头部有多少个32位bit(有多少个4字节),所以TCP头部最大的长度是15*4=60
6位标志位:
URG:紧急指针是否有效
ACK:确认号是否有效
PSH:提示接收端应用程序立刻从TCP缓冲区中把数据读走
RST:要求对方重新连接,我们把携带RST表示的称为复位报文段
SYN:请求建立连接,我们把携带SYN标识的称为同步报文段
FIN:通知对方,本端要关闭了.我们称携带FIN的叫结束报文段
16位校验和:发送端填充,CRC校验,如果接受端校验不通过,则认为数据有问题,这里的校验和不仅仅有TCP首部,也包含的有TCP数据部分
16位紧急指针:标识哪部分数据是紧急数据
40位头部选项和16位窗口大小;我会在后面的博客中详细介绍
2.TCP原理
TCP协议对于数据的管控主要有两个方面:安全和效率
在保证安全的时候,尽可能的提升效率
TCP是如何保证安全的呢,这就要涉及到我们的确认应答机制
2.1确认应答
我们用一张图来描述一下:
TCP协议对每个字节都进行了编号,有与之对应的序列号,当发送数据包到另一端以后,另一端就会确认应答发送应该数据包的最后一位+1,回馈给发送方,发送方下一次就以这个序列号为开始接着发.
2.2超时重传
在数据发送到接收方,没有得到及时响应的时候,就会触发超时重传机制.这也是TCP能保证安全的重要机制.
超时重传有以下两种情况:
1.数据发送给接收端的时候丢包
2.接收端确认应答的时候数据丢包,发送方不清楚数据是否到达,也会触发超时重传
这种情况,接收方会受到重复的数据,所以TCP协议会始别重复的包,并且把多余的给丢弃掉.
这时候我们就可以使用序列号来区分是不是相同的数据,很容易做到去重的效果.
那么这个超时重传的超时,具体时间如何确定呢?
如果时间太长的话,就会影响性能,而时间太短的话,极有可能会造成大量的重复包,造成资源浪费.
TCP协议为了兼顾到这两者,会动态的计算这个最大时间.
在Linux中(windows中也是如此),会以500ms为一个单位去控制,每次判定超时重传的时间都是这个数值的整数倍,如果依旧没有得到应答,就会在2*500ms的时间后再次重传,以此类推,每次都是上一次的两倍,但是如果时间过长又会发生什么呢?
答案是TCP会认为网络出现了问题,强制关闭连接.
3.三次握手(重点)
我们来深入理解,通过画图的方式来生动形象的的描述一下三次握手这个过程.
有的同学可能会有疑惑了,这明明是四次握手,为什么说是三次呢?实际上,第二次和第三次刚好一个在TCP协议格式第二位和第五位,刚好这两个可以一起发送过去,而TCP协议也确实是这样做的.
那么TCP协议的三次握手有什么好处呢?为什么不是两次不是四次,而偏偏是三次?且容我细细道来.
1.可以起到"投石问路"的效果,判断网络是否通畅,这个就像行军打仗的时候,前面的先锋部队会先去前面探路,确定路上没有阻碍了,后面的大部队才会跟着上来.
2.让发送端和接收端都能明白自己和对方的发送接收功能是否是好的.
比如在第一次握手的时候,接收端既然能收到请求就会知道 自己的接收功能莫问题,而发送端的发送功能莫问题
在第二次握手的时候,接收端返回一个应答报文和一个请求连接报文,接收端收到了以后,就知道自己的发送功能和接收功能都没问题.会回给接收端一个应答报文.
第三次握手的时候,接收端收到发送端的应答报文,就明白自己的发送功能和对方的接收功能都是好的.
这样,双方都明白自己和对方的发送功能和接收功能都是否完好.
如果是两次握手,那么就只是在我们上面提到的第二次握手,这样,接收端就不知道自己的发送功能和发送端的接收功能是不是好的,起不到我们想要的效果.
而三次握手已经满足了我们的需求,如果是四次或者多次,虽然也能做到,但是多余了,没有必要在做这么多重复没有意义的工作
