大佬教程收集整理的这篇文章主要介绍了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（最长报文段寿命）后，连接彻底关闭。
• ACK=1，seq=u+1，ack=w+1

TCP可靠传输

何谓可靠？

保证接收方进程从缓存区读出的字节流与发送方发出的字节流是完全一样的

传输层 使用TCP实现可靠传输 网络层 提供尽最大努力交付，不可靠传输

TCP实现可靠传输的机制

• 1.校验（与UDP校验一样， 增加伪首部）
• 2.序号
• 3.确认
• 4.重传

序号

确认

这里即使得到了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号报文段

大佬总结

以上是大佬教程为你收集整理的5.4 TCP 连接全部内容，希望文章能够帮你解决5.4 TCP 连接所遇到的程序开发问题。

如果觉得大佬教程网站内容还不错，欢迎将大佬教程推荐给程序员好友。

本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。