5.4 TCP 连接
5.4 TCP 连接
三个阶段:
- 连接建立
- 数据传送
- 连接释放
TCP连接的建立采用客户服务器方式,主动发起连接建立的应用进程叫做客户,而被动等待连接建立的应用进程叫服务器。
三 次 握 手
A:有件事不知当讲不当讲
B:请讲
A:好的!#$%!#$%...
TCP的连接建立
假设运行在一台主机(客户)上的一个进程想与另一台主机(服务器)上的一个进程建立一条连接,客户应用 进程首先通知客户TCP,他想建立一个与服务器上某个进程之间的连接,客户中的TCP会用以下步骤与服务器中 的TCP建立一条TCP连接:

ROUND 1:
- 客户端发送连接请求报文段,无应用层数据。
- SYN=1,seq=x(随机)
ROUND 2:
- 服务器端为该TCP连接分配缓存和变量,并向客户端返回确认报文段,允许连接,无应用层数据。
- SYN=1,ACK=1,seq=y(随机),ack=x+1
ROUND 3:
- 客户端为该TCP连接分配缓存和变量,并向服务器端返回确认的确认,可以携带数据。
- SYN=0,ACK=1,seq=x+1,ack=y+1
SYN洪泛攻击
- SYN洪泛攻击发生在OSI第四层(传输层),这种方式利用TCP协议的特性,就是三次握手。
- 攻击者发送TCP SYN,SYN是TCP三次握手中的第一个数据包,而当服务器返回ACK后,该攻击者就不对 其进行再确认,那这个TCP连接就处于挂起状态,也就是所谓的半连接状态,也就是不发送第三次的握手。
- 服务器收不到 再确认的话,还会重复发送ACK给攻击者。这样更加会浪费服务器的资源。
- 攻击者就对服务器发送非常大量的这种TCP连接,由于每一个都没法完成三次握手,所以在服务器上,这些 TCP连接会因为挂起状态而消耗CPU和内存,最后服务器可能死机,就无法为正常用户提供服务了。
解决办法
SYN cookie
TCP的连接释放
参与一条TCP连接的两个进程中的任何一个都能终止该连接,连接结束后,主机中的“资源”(缓存和变量)将被 释放。
A:我说完了
B:好的,到我了,balabala
B:bye
A:OK,bye

ROUND 1:
- 客户端发送连接释放报文段,停止发送数据,主动 关闭TCP连接。
- FIN=1,seq=u
ROUND 2:
- 服务器端回送一个确认报文段,客户到服务器这个方向的连接就释放了——半关闭状态。
- ACK=1,seq=v,ack=u+1
ROUND 3:
- 服务器端发完数据,就发出连接释放报文段,主动关闭TCP连接。
- FIN=1,ACK=1,seq=w,ack=u+1
ROUND 4:
- 客户端回送一个确认报文段,再等到时间等待计时器设置的2MSL(最长报文段寿命,若不等待,将导致服务器B的连接一直不关闭)后,连接彻底关闭。
- ACK=1,seq=u+1,ack=w+1
TCP可靠传输
何谓可靠?
保证接收方进程从缓存区读出的字节流与发送方发出的字节流是完全一样的
传输层
使用TCP实现可靠传输
网络层
提供尽最大努力交付,不可靠传输
TCP实现可靠传输的机制
- 1.校验(与UDP校验一样, 增加伪首部)
- 2.序号
- 3.确认
- 4.重传
序号

并且要等到对方收到了123过后,A才会删除自己的123副本。
确认

这里即使得到了1、2、3、7、8,但是由于4、5、6还是没有抵达,TCP还惦记着的,故报文段首部确认号字段为4
重传
确认重传不分家,TCP的发送方在规定的时间内没有收到确认就要重传已发送的报文段
重传时间:TCP采用自适应算法,动态改变重传时间RTTS (加权平均往返时间)。
(若重传时间长,负载大,时间短,难以确定是否收到。)

冗余确认
冗余ACK(冗余确认)
每当比期望序号大的失序报文段到达时,发送一个冗余ACK,指明下一个期待字节的序号。
如:发送方已发送1,2,3,4,5报文段
- 接收方收到1,返回给1的确认(确认号为2的第一个字节)
- 接收方收到3,仍返回给1的确认(确认号为2的第一个字节)
- 接收方收到4,仍返回给1的确认(确认号为2的第一个字节)
- 接收方收到5,仍返回给1的确认(确认号为2的第一个字节)
- ==> 发送方收到3个对于报文段1的冗余ACK —— 认为2号报文段丢失,重传2号报文段