◼
SYN(Synchronization)
当SYN=1、ACK=0时,表明这是一个建立连接的请求
若对方同意建立连接,则回复SYN=1、ACK=1
◼
FIN(Finish)
当FIN=1时,表明数据已经发送完毕,要求释放连接
TCP--确认号,序号,端口
◼
序号(Sequence Number)
占4字节
首先,在传输过程的每一个字节都会有一个编号
在建立连接后,序号代表:这一次传给对方的TCP数据部分的第一个字节的编号
◼
确认号(Acknowledgment Number)
占4字节
在建立连接后,确认号代表:期望对方下一次传过来的TCP数据部分的第一个字节的编号
◼
窗口(Window)
占2字节
这个字段有流量控制功能,用以告知对方下一次允许发送的数据大小(字节为单位)
TCP重要考点
◼ 可靠传输
所谓的可靠,就是能保证数据的正确性,无差错、不丢失、不重复、并且按序达到
TCP--可靠传输--停止等待ARQ协议
◼
ARQ(
A
utomatic
R
epeat–re
Q
uest),自动重传请求
TCP--可靠传输--停止等待ARQ协议--滑动窗口协议
TCP--可靠传输--停止等待ARQ协议--SACK协议
◼
在TCP通信过程中,如果发送序列中间某个数据包丢失(比如1、2、
3
、4、5中的
3
丢失了)
◼
TCP会通过重传最后确认的分组后续的分组(最后确认的是2,会重传
3
、4、5)
◼
这样原先已经正确传输的分组也可能重复发送(比如4、5),降低了TCP性能
◼
为改善上述情况,发展出了SACK(Selective acknowledgment,选择
性
确认)技术
告诉发送方哪些数据丢失,哪些数据已经提前收到
使TCP只重新发送丢失的包(比如
3
),不用发送后续所有的分组(比如4、5)
◼
如果接收窗口最多能接收4个包
但发送方只发了2个包
◼
接收方如何确定后面还有没有2个包?
等待一定时间后没有第3个包
就会返回确认收到2个包给发送方
◼
为什么选择在传输层就将数据“大卸八块”分成多个段,而不是等到网络层再分片传递给数据链路层?
因为可以提高重传的性能
需要明确的是:可靠传输是在传输层进行控制的
✓ 如果在传输层不分段,一旦出现数据丢失,整个传输层的数据都得重传
✓ 如果在传输层分了段,一旦出现数据丢失,只需要重传丢失的那些段即可
◼ 流量控制
◼
如果接收方的缓存区满了,发送方还在疯狂着发送数据
接收方只能把收到的数据包丢掉,大量的丢包会极大着浪费网络资源
所以要进行流量控制
◼
什么是流量控制?
让发送方的发送速率不要太快,让接收方来得及接收处理
◼
原理
通过确认报文中窗口字段来控制发送方的发送速率
发送方的发送窗口大小不能超过接收方给出窗口大小
当发送方收到接收窗口的大小为0时,发送方就会停止发送数据
◼ 有一种特殊情况
一开始,接收方给发送方发送了0窗口的报文段
后面,接收方又有了一些存储空间,给发送方发送的非0窗口的报文段丢失了
发送方的发送窗口一直为零,双方陷入僵局
◼
解决方案
当发送方收到0窗口通知时,这时发送方停止发送报文
并且同时开启一个定时器,隔一段时间就发个测试报文去询问接收方最新的窗口大小
如果接收的窗口大小还是为0,则发送方再次刷新启动定时器
◼ 拥塞控制(慢开始,拥塞避免,快速重传,快速恢复)
◼
拥塞控制
防止过多的数据注入到网络中
避免网络中的路由器或链路过载
◼
拥塞控制是一个全局性的过程
涉及到所有的主机、路由器
以及与降低网络传输性能有关的所有因素
是大家共同努力的结果
◼
相比而言,流量控制是点对点通信的控制,即接收端控制发送端,它所要做的是抑制发送端发送数据的速率,以便使接收端来得及接收。
◼
几个缩写
MSS(Maximum Segment Size):每个段最大的数据部分大小
✓
在建立连接时确定
cwnd(congestion window):拥塞窗口
rwnd(receive window):接收窗口
swnd(send window):发送窗口
✓
swnd = min(cwnd, rwnd)
慢开始
◼
cwnd的初始值比较小,然后随着数据包被接收方确认(收到一个ACK)
cwnd就成倍增长(指数级)
拥塞避免
◼
ssthresh(slow start threshold):慢
开始
阈值,cwnd达到阈值后,以线性方式增加
◼
拥塞避免(加法增大):拥塞窗口缓慢增大,以防止网络过早出现拥塞
◼
乘法减小:只要网络出现拥塞,把ssthresh减为拥塞峰值的一半,同时执行慢开始算法(cwnd又恢复到初始值)
当网络出现频繁拥塞时,ssthresh值就下降的很快
快重传
◼
接收方
每收到一个失序的分组后就立即发出重复确认
使发送方及时知道有分组没有到达
而不要等待自己发送数据时才进行确认
◼
发送方
只要连续收到三个重复确认(总共4个相同的确认),就应当立即重传对方尚未收到的报文段
而不必继续等待重传计时器到期后再重传
快恢复
◼
当发送方连续收到三个重复确认,说明网络出现拥塞
就执行“乘法减小”算法,把ssthresh减为拥塞峰值的一半
◼
与慢开始不同之处是现在不执行慢开始算法,即cwnd现在不恢复到初始值
而是把cwnd值设置为新的ssthresh值(减小后的值)
然后开始执行拥塞避免算法(“加法增大”),使拥塞窗口缓慢地线性增大
◼
发送窗口的最大值:swnd = min(cwnd, rwnd)
◼
当rwnd < cwnd时,是接收方的接收能力限制发送窗口的最大值
◼
当cwnd < rwnd时,则是网络的拥塞限制发送窗口的最大值
TCP--确认号,序列号
注意蓝色和紫色颜色区别
TCP--三次握手
◼
CLOSED
:client处于关闭状态
◼
LISTEN
:server处于监听状态,等待client连接
◼
SYN-RCVD
:表示server接受到了SYN报文,当收到client的ACK报文后,它会进入到
ESTABLISHED
状态
◼
SYN-SENT
:表示client已发送SYN报文,等待server的第2次握手
◼
ESTABLISHED
:表示连接已经建立
◼ 为什么建立连接的时候,要进行3次握手?2次不行么?
主要目的:防止server端一直等待,浪费资源
◼
如果建立连接只需要2次握手,可能会出现的情况
假设client发出的第一个连接请求报文段,因为网络延迟,在连接释放以后的某个时间才到达server
本来这是一个早已失效的连接请求,但server收到此失效的请求后,误认为是client再次发出的一个新的连接请求
于是server就向client发出确认报文段,同意建立连接
如果不采用“3次握手”,那么只要server发出确认,新的连接就建立了
由于现在client并没有真正想连接服务器的意愿,因此不会理睬server的确认,也不会向server发送数据
但server却以为新的连接已经建立,并一直等待client发来数据,这样,server的很多资源就白白浪费掉了
◼
采用“三次握手”的办法可以防止上述现象发生
例如上述情况,client没有向server的确认发出确认,server由于收不到确认,就知道client并没有要求建立连接
◼
第3次握手失败了,会怎么处理?
此时server的状态为SYN-RCVD,若等不到client的ACK,server会重新发送SYN+ACK包
如果server多次重发SYN+ACK都等不到client的ACK,就会发送RST包,强制关闭连接
从上面的过程可以发现
第三次握手是可以携带数据的,前两次握手是不可以携带数据的,这也是面试常问的题。
◼TCP--四次挥手
◼
为什么释放连接的时候,要进行4次挥手?
TCP是全双工模式
第1次挥手:当
主机1
发出FIN报文段时
✓
表示
主机1
告诉
主机2
,
主机1
已经没有数据要发送了,但是,此时
主机1
还是可以接受来自
主机2
的数据
第2次挥手:当
主机2
返回ACK报文段时
✓
表示
主机2
已经知道
主机1
没有数据发送了,但是
主机2
还是可以发送数据到
主机1
的
第3次挥手:当
主机2
也发送了FIN报文段时
✓
表示
主机2
告诉
主机1
,
主机2
已经没有数据要发送了
第4次挥手:当
主机1
返回ACK报文段时
✓
表示
主机1
已经知道
主机2
没有数据发送了。随后正式断开整个TCP连接
从上面过程可知,服务端通常需要等待完成数据的发送和处理,所以服务端的 ACK
和 FIN
一般都会分开发送,从而比三次握手导致多了一次。
为什么 TIME_WAIT 等待的时间是 2MSL?
MSL
是 Maximum Segment Lifetime,
报文最大生存时间,它是任何报文在网络上存在的最长时间,超过这个时间报文将被丢弃。
网络中可能存在来自发送方的数据包,当这些发送方的数据包被接收方处理后又会向对方发送响应,所以
一来一回需要等待 2 倍的时间。
为什么需要 TIME_WAIT 状态?
原因一:防止旧连接的数据包
假设 TIME-WAIT 没有等待时间或时间过短,被延迟的数据包抵达后会发生什么呢?
所以,TCP 就设计出了这么一个机制,经过 2MSL
这个时间,足以让两个方向上的数据包都被丢弃,使得原来连接的数据包在网络中都自然消失,再出现的数据包一定都是新建立连接所产生的。
原因二:保证连接正确关闭
假设 TIME-WAIT 没有等待时间或时间过短,断开连接会造成什么问题呢?
所以客户端在 TIME-WAIT
状态等待 2MSL
时间后,就可以保证双方的连接都可以正常的关闭。