tcp运输连接阶段（tcp运输连接的三个阶段）

大家好！今天让创意岭的小编来大家介绍下关于tcp运输连接阶段的问题，以下是小编对此问题的归纳整理，让我们一起来看看吧。

开始之前先推荐一个非常厉害的Ai人工智能工具，一键生成原创文章、方案、文案、工作计划、工作报告、论文、代码、作文、做题和对话答疑等等

只需要输入关键词，就能返回你想要的内容，越精准，写出的就越详细，有微信小程序端、在线网页版、PC客户端

官网：https://ai.de1919.com

本文目录:

• 1、TCP连接相关

• 2、面向连接和无连接是强调通信必须经过什么样的阶段？

• 3、04 - TCP和UDP的认识和区别

• 4、计算机网络——TCP三次握手四次挥手

一、TCP连接相关

为什么要有三次握手，因为如果只有两次握手，那么

第一次：客户端发送一个syn包给服务器，里面有一个随机生成的syn，然后客户端处于syn_send状态

第二次：服务端收到客户端发来的syn包之后，确认syn包，也就是生成一个ack=syn+1，然后再自己随机生成一个syn包，即syn+ack包，然后返回给客户端，自己变成syn_recv状态

第三次：客户端收到服务端发来的syn+ack包之后，确认ack是正确的之后，返回一个ack=syn+1给服务端，此包发送完毕，客户端进入了ESTABLISHED状态，服务端收到ack包后也进入ESTABLISHED状态。

SYN攻击，当第二次握手服务端发送了syn+ack包之后，收到客户端发送的ack之前这段时间的tcp链接成为半连接，此时服务端处于syn_recv状态。当大量客户端随机IP疯狂发送tcp链接请求时，客户端以为是不同用户的请求，所以队列中全是半连接，然后导致服务器宕机，正常请求被丢弃。

第一个包发送过程丢失

A会周期性超时重传，直到收到B的确认

第二个包发送过程丢失

B会周期性超时重传，直到收到A的确认

第三个包发送过程丢失

A发送完数据后单方面进入TCP的ESTABLISHED状态，B还处于半链接：

TCP协议为什么需要三次握手？

第一次：客户端发送一个fin给服务端表示自己要断开连接了，然后进入fin_wait_1状态

第二次：服务端收到fin后，发送一个ack=fin+1给客户端，服务端进入close_wait状态，客户端进入fin_wait_2状态

第三次：服务端发送一个fin，用来关闭服务端到客户端的数据传输，服务端进入last_ack状态

第四次：客户端收到fin后，进入time_wait状态，然后发送一个ack=fin+1给服务端，服务端确认后进入close状态，完成四次挥手

TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式，这就意味着，当主机1发出FIN报文段时，只是表示主机1已经没有数据要发送了，主机1告诉主机2，它的数据已经全部发送完毕了；但是，这个时候主机1还是可以接受来自主机2的数据；当主机2返回ACK报文段时，表示它已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的；当主机2也发送了FIN报文段时，这个时候就表示主机2也没有数据要发送了，就会告诉主机1，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。如果要正确的理解四次分手的原理，就需要了解四次分手过程中的状态变化。

答案解析：

浏览器对并发请求的数目限制是针对域名的，即针对同一域名（包括二级域名）在同一时间支持的并发请求数量的限制。如果请求数目超出限制，则会阻塞。因此，网站中对一些静态资源，使用不同的一级域名，可以提升浏览器并行请求的数目，加速界面资源的获取速度。

在 HTTP/1.0 中，一个http请求收到服务器响应后，会断开对应的TCP连接。这样每次请求，都需要重新建立TCP连接，这样一直重复建立和断开的过程，比较耗时。所以为了充分利用TCP连接，可以设置头字段 Connection: keep-alive ，这样http请求完成后，就不会断开当前的TCP连接，后续的http请求可以使用当前TCP连接进行通信。

第一次访问有初始化连接和SSL开销

初始化连接和SSL开销消失了，说明使用的是同一个TCP连接。

HTTP/1.1 将 Connection 写入了标准，默认值为 keep-alive 。除非强制设置为 Connection: close ，才会在请求后断开TCP连接。

所以这一题的答案就是：默认情况下建立的TCP连接不会断开，只有在请求头中设置 Connection: close 才会在请求后关闭TCP连接。

HTTP/1.1 中，单个TCP连接，在同一时间只能处理一个http请求，虽然存在Pipelining技术支持多个请求同时发送，但由于实践中存在很多问题无法解决，所以浏览器默认是关闭，所以可以认为是不支持同时多个请求。

HTTP2 提供了多路传输功能，多个http请求，可以同时在同一个TCP连接中进行传输。

页面资源请求时，浏览器会同时和服务器建立多个TCP连接，在同一个TCP连接上顺序处理多个HTTP请求。所以浏览器的并发性就体现在可以建立多个TCP连接，来支持多个http同时请求。

Chrome浏览器最多允许对同一个域名Host建立6个TCP连接，不同的浏览器有所区别。

补充

如果图片都是HTTPS的连接，并且在同一域名下，浏览器会先和服务器协商使用 HTTP2 的 Multiplexing 功能进行多路传输，不过未必所有的挂在这个域名下的资源都会使用同一个TCP连接。如果用不了HTTPS或者HTTP2（HTTP2是在HTTPS上实现的），那么浏览器会就在同一个host建立多个TCP连接，每一个TCP连接进行顺序请求资源。

参考：

[1]. 第8题-浏览器HTTP请求并发数和TCP连接的关系

二、面向连接和无连接是强调通信必须经过什么样的阶段？

面向连接必须经过三个阶段:“建立连接一传送数据一释放连接”，而无连接则只有一个阶段:“传送数据”。电路交换和分组交换则是强调在通信时用户对网络资源的占用方式。电路交换是在连接建立后到连接释放前全程占用信道资源，而分组交换则强调在数据传送时断续占用信道资源(分组在哪一条链路上传送就占用哪一条链路的信道资源)。面向连接和无连接往往可以在不同的层次上来讨论。例如，在数据链路层，HDLC和PPP协议是面向连接的，而以太网使用的CSMA/CD则是无连接的(见教材3.3.2节)。在网络层，X.25协议是面向连接的，而IP协议则是无连接的。在运输层，TCP是面向连接的，而UDP则是无连接的。但是我们却不能说:“TCP是电路交换”，而应当说:“TCP可以向应用层提供面向连接的服务”。需要注意的是，在运输层的面向连接中的“连接”，并非是“物理上的连接”。这点我们将在讨论运输层时再深入研究。面向连接必须经过三个阶段:“建立连接一传送数据一释放连接”，而无连接则只有一个阶段:“传送数据”。电路交换和分组交换则是强调在通信时用户对网络资源的占用方式。电路交换是在连接建立后到连接释放前全程占用信道资源，而分组交换则强调在数据传送时断续占用信道资源(分组在哪一条链路上传送就占用哪一条链路的信道资源)。

面向连接和无连接往往可以在不同的层次上来讨论。例如，在数据链路层，HDLC和PPP协议是面向连接的，而以太网使用的CSMA/CD则是无连接的(见教材3.3.2节)。在网络层，X.25协议是面向连接的，而IP协议则是无连接的。在运输层，TCP是面向连接的，而UDP则是无连接的。但是我们却不能说:“TCP是电路交换”，而应当说:“TCP可以向应用层提供面向连接的服务”。需要注意的是，在运输层的面向连接中的“连接”，并非是“物理上的连接”。这点我们将在讨论运输层时再深入研究。

三、04 - TCP和UDP的认识和区别

本文主要分析运输层的两种协议TCP和UDP，重点在于TCP如何实现可靠传输，并且进行流量控制，以及TCP的三次握手和四次挥手的详细过程。最后对TCP和TDP的两种协议进行了比较。

TCP的拥塞控制已在另一篇博客 拥塞控制的基本方法 说明，本文不再赘述.

运输层就是位于应用层和网络层之间的，为运行在不同主机上的应用进程提供直接的通信服务是运输层的任务。

物理层、数据链路层以及网络层他们共同解决了将主机通过异构网络互连起来所面临的问题，实现了主机到主机的通信，而通信的真正实体是位于通信两端主机中的进程。

因特网的运输层为应用层提供了两种不同的运输协议，即面向连接的TCP和无连接的UDP

UDP是无连接的，不可靠的运输协议，TCP是面向连接的，可靠的运输协议

运输层在网络通信中的作用：

运输层在网络通信中作用过程：

注：这里所说的主机和主机之间的通信其实是主机进程之间的通信

用户数据报协议(User Datagram Protocol)，是TCP/IP体系结构运输层中的一个重要协议，这种逻辑通信信道是一条不可靠信道。

特点：

说明：

TCP 是TCP/IP体系结构运输层中的重要协议，当运输层采用面向连接的 TCP 协议时，尽管下面的网络是不可靠的（只提供尽最大努力服务），但这种逻辑通信信道就相当于一条全双工的可靠信道。

TCP 传送的数据单位协议是 TCP 报文段(segment)

特点：

TCP传输过程

说明：

发送方：

接收方：

在TCP传输中为了实现可靠传输和流量控制都需要涉及超时重传，超时重传中最为重要的是计算超时重传的时间。

RTO是超时重传时间，RTT是往返时间。

超时重传时间不能远大于往返时间，会浪费资源

超时重传时间不能小于往返时间，会造成不必要的重传

超时重传时间应当略大于往返时间，为了避免误差，应当选用一段时间内的加权的往返时间

总结：

1、如果超时重传时间RTO的值设置得比RTT的值小很多，这会引起报文段不必要的重传，使网络负荷增大

2、如果超时重传时间RTO的值设置得远大于RTT0的值，这会使重传时间推迟的太长，使网络的空闲时间增大，降低传输效率

3、因此需要将超时重传时间设置的略大于一次往返时间。

超时重传时间的要略大于一次往返时间，但一次往返时间是不固定的，因此超时重传时间的计算是基于加权平均往返时间

说明：

往返时间RTT的测量不能简单的进行一次往返时间的计算，有如下问题需要处理

问题1：如果报文丢失或确认报文的迟到，都会导致重传报文。这样两次的报文发送使得无法准确计算一次往返时间。

解决1：Karn算法

问题2：

对于问题1的解决会引入新问题

解决2：

利用滑动窗口机制来实现流量控制，重点有两个，一个是接收方通过对已接收的数据进行累计确认，并调整窗口大小，来对发送方进行流控，第二个就是启动持续计时器来探知是否要发送零窗口探测报文，通过这两个就可以让接收方对发送方进行窗口大小的调控，以此做到了流量控制。

一般来说，我们总是希望数据传输的更快一些，但是如果发送方把数据发送的过快，接收方就可能来不及接收，这就会造成数据的丢失。所以就需要进行流量控制，

流量控制简单说就是让发送方的发送速率不要太快，要让接收方来得及接收

我们利用滑动窗口机制可以很方便的在TCP连接上实现对发送方的流量控制

重点在于接收方根据自己的存储空间来决定自己的接收空间的大小，以此来限制发送方发送窗口的大小

过程：

说明：

接收方给发送方发送的确认报文丢失后会形成A和B主机的相互等待，这样就造成了死锁，需要通过一个持续计时器，当计时器为0时发送零窗口探测报文询问以此让接收方再次发送确认报文。这样就打破了死锁

说明：

零窗口探测报文丢失后，是否仍然会死锁？

零窗口探测报文发送到主机B时，主机B的接收窗口为0，还能接收零窗口探测报文吗

可靠传输是通过确认机制来实现的，接收方给发送方发送的确认报文带有的字段决定了发送方是否要重传，是否要滑动窗口的操作，以此做到了可靠传输

说明：

TCP是面向连接的协议，它基于运输连接来传送TCP报文段，TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的部分。

TCP的运输连接管理就是使运输连接的建立和释放都能正常的进行。

共有三个阶段

过程示意图：

说明：

为什么必须要三次握手，不能两次握手？

TCP双方已经建立了连接，后来，TCP客户进程所在的主机突然出现了故障，TCP服务器进程以后就不能再收到TCP客户进程发来的数据，因此，应当有措施使TCP服务器进程不要再白白等待下去。

四、计算机网络——TCP三次握手四次挥手

用户进程和服务器进程需要完成一次通信都需要完成 三个阶段 ： 连接建立、数据传送、连接释放

参考：三次握手和四次挥手

首先先明确几个概念：

序列号seq（4B） ：用来标记数据段的顺序，TCP把连接中发送的所有数据字节都编上一个序号，第一个字节的编号由本地随机产生，给字节编上序号后，就给每一个报文段指派一个序号， 序列号seq就是这个报文段中的第一个字节的数据编号 。

确认号ack（4B） ： 期待收到对方下一个报文段的第一个数据字节的序号 ，序列号表示报文段携带数据的第一个字节的编号，而确认号指的是期望接受到下一个字节的编号，因此挡墙报文段最后一个字节的编号+1即是确认号。

确认ACK（1bit） ：仅当ACK=1，确认号字段才有效。ACK=0，确认号无效。

同步SYN ： 连接建立时 用于同步序号。SYN=1表示这是一个连接请求，或连接接收报文，SYN这个标志位只有在TCP建立连接才会被置为1，握手完成后SYN标志位被置为0.当SYN=1，ACK=0表示：这是一个连接请求报文段。若同意连接，则在响应报文段中使用SYN=1，ACK=1

终止FIN ：用来释放一个连接。

B的TCP服务器进程先创建传输控制块TCB，准备接受客户进程的连接请求。然后服务器进程就处于LISTEN（收听）状态，等待客户的连接请求。若有，则作出响应。

1）第一次握手：A首先向B发一个SYN (Synchronize) 标记的包，告诉B请求建立连接，一个 SYN包就是仅SYN标记设为1的TCP包(参见TCP包头Resources)， SYN=1的报文段不能携带数据 ，但要 消耗掉一个序号， 此时TCP客户进程进入SYN-SENT（同步已发送）状态。

2）第二次握手：B收到后会发一个对SYN包的确认包(SYN/ACK)回去，表示对第一个SYN包的确认，并继续握手操作.注意: SYN/ACK包是仅SYN 和 ACK 标记为1的包。在确认报文段中，测试TCP服务器进程进入SYN-RCVD（同步收到）状态；

3）第三次握手：TCP客户进程收到B的确认后，要向B给出确认报文段，ACK报文段可以携带数据，不携带数据则不消耗序号。TCP连接已经建立，A进入ESTABLISHED（已建立连接）。

当B收到A的确认后，也进入建立连接状态。

序列号和确认号的关系：

第一次握手序列号seq=x；

第二次握手序列号seq=y，确认号ack=x+1；

第三次握手序列号seq=x+1，确认号ack=y+1；

序列号seq是上一次的确认号，而确认号是上一次的序列号+1;这是因为SYN=1的报文段不能携带数据，但要消耗掉一个序号，所以下一个报文段要+1；

为了防止已经失效的连接请求报文段突然又传到服务端，因而产生错误”，这种情况是：一端(client)A发出去的第一个连接请求报文并没有丢失，而是因为某些未知的原因在某个网络节点上发生滞留，导致延迟到连接释放以后的某个时间才到达另一端(server)B。本来这是一个早已失效的报文段，但是B收到此失效的报文之后，会误认为是A再次发出的一个新的连接请求，于是B端就向A又发出确认报文，表示同意建立连接。如果不采用“三次握手”，那么只要B端发出确认报文就会认为新的连接已经建立了，但是A端并没有发出建立连接的请求，因此不会去向B端发送数据，B端没有收到数据就会一直等待，这样B端就会白白浪费掉很多资源。如果采用“三次握手”的话就不会出现这种情况，B端收到一个过时失效的报文段之后，向A端发出确认，此时A并没有要求建立连接，所以就不会向B端发送确认，这个时候B端也能够知道连接没有建立。（知乎上对上面的解释的评论：这个解答不是问题的本质，这个课本很多知识比较片面。问题的核心在于保证信道数据传输的可靠性，避免资源浪费仅仅是一个小的弱原因，不重要。） 

从客户端到服务端释放连接的过程中，需要四次报文传输。

TCP四次挥手过程

1）A的应用进程先向其TCP发出连接释放报文段（FIN=1，序号seq=u），并停止再发送数据，主动关闭TCP连接，进入FIN-WAIT-1（终止等待1）状态，等待B的确认。

2）B收到连接释放报文段后即发出确认报文段，（ACK=1，确认号ack=u+1，序号seq=v），B进入CLOSE-WAIT（关闭等待）状态，此时的TCP处于半关闭状态，A到B的连接释放。

3）A收到B的确认后，进入FIN-WAIT-2（终止等待2）状态，等待B发出的连接释放报文段。

4）B没有要向A发出的数据，B发出连接释放报文段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），B进入LAST-ACK（最后确认）状态，等待A的确认。

5）A收到B的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），A进入TIME-WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，A才进入CLOSED状态。

大概就是A和B：

A：“我不和你说话了”

B：“知道了”

此时A单方面不和B说话，当B也没有话对A说的时候

B：“我也不和你说话了”

A：“好的”

两个人互相不说话了

TCP四次挥手总结

客户端发送FIN后，进入终止等待状态，服务器收到客户端连接释放报文段后，就立即给客户端发送确认，服务器就进入CLOSE_WAIT状态，此时TCP服务器进程就通知高层应用进程，因而从客户端到服务器的连接就释放了。此时是“半关闭状态”，即客户端不可以发送给服务器，服务器可以发送给客户端。

此时，如果服务器没有数据报发送给客户端，其应用程序就通知TCP释放连接，然后发送给客户端连接释放数据报，并等待确认。客户端发送确认后，进入TIME_WAIT状态，但是此时TCP连接还没有释放，然后经过等待计时器设置的2MSL后，才进入到CLOSE状态。

以上就是关于tcp运输连接阶段相关问题的回答。希望能帮到你，如有更多相关问题，您也可以联系我们的客服进行咨询，客服也会为您讲解更多精彩的知识和内容。

推荐阅读：

简述TCP与UDP及其区别（简述tcp与udp的主要区别）

rocketchat安卓（rocketchat安卓下载）

全部tcpip协议有100多个（全部tcpip协议有多少个）

ChatGPT概念龙头股大胜达（大胜达股票代码）

小红书上怎么卖货（小红书上怎么卖货赚钱）_1