❶ tcp连接建立和断开过程
tcp的建立必须有一方主动，举个通俗的例子 ：男孩客户端，女孩服务端，用他们之间的交往说明三次握手的过程
1、男孩喜欢女孩，写了一封信告诉女孩：你长得漂亮，我稀罕你！写完信之后，男孩焦急地等待，因为不知道信能否顺利传达给女孩。SYN=1，seq=X
2、女孩收到男孩的情书后，心花怒放，于是回信：我收到你的情书了，其实，我也喜欢你！我愿意和你交往！;写完信之后，女孩也焦急地等待，因为不知道回信能否能顺利传达给男孩。SYN=1，ack=x+1,seq=y
3、男孩收到回信之后很开心，因为发出的情书女孩收到了，并且从回信中知道了女孩喜欢自己，并且愿意和自己交往。然后男孩又写了一封信告诉女孩：你的心意和信我都收到了，谢谢你，还有我爱你 SYN=1,ack=Y+1,seq=X+1
彼此都收到回信，大家开心交流了起来。这就是通俗版的“三次握手”，期间一共往来了三封信也就是“三次握手”，以此确认两个方向上的数据传输通道是否正常。
tcp断开，也是有一方主动，也用这个例子。
"第一次挥手"：男：你太懒了，我要和你分手 FIN=1,seq=x
“第二次挥手”：女：好，臭男人，等我把我的东西收拾完 FIN=1，ack=X+1,seq=y
男孩收到女孩的第一封信之后，明白了女孩知道自己要和她分手。随后等待女孩把自己的东西收拾好。
“第三次挥手”：过了几天，女孩把男孩送的东西都整理好了，女：臭男人，我的东西收拾完了，咱们分手吧！FIN=1，ack=X+1,seq=z
“第四次挥手”：男：好，拜拜！ FIN=1，ack=z+1,seq=h
当然这里双方都有各自的坚持。女孩自发出第二封信开始，限定一天内收不到男孩回信，就会再发一封信催促男孩来取东西！男孩自发出第二封信开始，限定两天内没有再次收到女孩的信就认为，女孩收到了自己的第二封信；若两天内再次收到女孩的来信，就认为自己的第二封信女孩没收到，需要再写一封信，再等两天…..
倘若双方信都能正常收到，最少只用四封信就能彻底分手！这就是“四次挥手”。
❷ 简述TCP连接建立与断开的过程
TCP 是一个面向连接的协议，无论哪一方向另一方发送数据之前，都必须先在双方之间建立一条连接。本节将详细讨论一个TCP 连接是如何建立的以及通信结束后是如何终止的。
建立一个 TCP 连接
TCP使用三次握手 （ three-way handshake ） 协议来建立连接，图 3-10 描述了三次握手的报文序列。这三次握手为：
请求端（通常称为客户）发送一个 SYN 报文段（ SYN 为 1 ）指明客户打算连接的服务器的端口，以及初始顺序号（ ISN ）。
服务器发回包含服务器的初始顺序号的 SYN 报文段（ SYN 为 1 ）作为应答。同时，将确认号设置为客户的 ISN 加 1 以对客户的 SYN 报文段进行确认（ ACK 也为 1 ）。
客户必须将确认号设置为服务器的 ISN 加 1 以对服务器的 SYN 报文段进行确认（ ACK 为 1 ），该报文通知目的主机双方已完成连接建立。
发送第一个 SYN 的一端将执行主动打开（ active open ），接收这个 SYN 并发回下一个 SYN 的另一端执行被动打开（ passive open ）。另外， TCP 的握手协议被精心设计为可以处理同时打开（ simultaneous open ），对于同时打开它仅建立一条连接而不是两条连接。因此，连接可以由任一方或双方发起，一旦连接建立，数据就可以双向对等地流动，而没有所谓的主从关系。
三次握手协议是连接两端正确同步的充要条件。因为 TCP 建立在不可靠的分组传输服务之上，报文可能丢失、延迟、重复和乱序，因此协议必须使用超时和重传机制。如果重传的连接请求和原先的连接请求在连接正在建立时到达，或者当一个连接已经建立、使用和结束之后，某个延迟的连接请求才到达，就会出现问题。采用三次握手协议（加上这样的规则：在连接建立之后 TCP 就不再理睬又一次的连接请求）就可以解决这些问题。
三次握手协议可以完成两个重要功能：它确保连接双方做好传输准备，并使双方统一了初始顺序号。初始顺序号是在握手期间传输顺序号并获得确认：当一端为建立连接而发送它的 SYN 时，它为连接选择一个初始顺序号；每个报文段都包括了顺序号字段和确认号字段，这使得两台机器仅仅使用三个握手报文就能协商好各自的数据流的顺序号。一般来说， ISN 随时间而变化，因此每个连接都将具有不同的 ISN 。
关闭一个 TCP 连接
TCP 连接建立起来后，就可以在两个方向传送数据流。当 TCP 的应用进程再没有数据需要发送时，就发关闭命令。 TCP 通过发送控制位 FIN=1 的数据片来关闭本方数据流，但还可以继续接收数据，直到对方关闭那个方向的数据流，连接就关闭。
TCP 协议使用修改的三次握手协议来关闭连接， 如图 3-11 所示，即终止一个连接要经过 4 次握手。这是因为 TCP 的半关闭（ half-close ）造成的。由于一个 TCP 连接是全双工（即数据在两个方向上能同时传递），因此每个方向必须单独地进行关闭。关闭的原则就是当一方完成它的数据发送任务后就能发送一个 FIN 来终止这个方向连接。当一端收到一个 FIN ，它必须通知应用层另一端已经终止了那个方向的数据传送。发送 FIN 通常是应用层进行关闭的结果。
❸ 怎样强制断开TCP连接
TCP通信的话，服务端断开时会自动通知客户端客户端处理该事件就可以了
❹ tcp连接的断开
TCP的断开就是经过四次挥手：
这是正常的情况，客户端主动tcp连接断开的过程。客户端先是发送一个FIN为一的报文，然后进入FIN_WAIT_1的状态。
服务器收到FIN报文后，发送一个ACK报文，然后进入CLOSED_WAIT状态。
客户端收到服务器的ACK报文进入FIN_WAIT_2状态。
等到服务器觉得他数据处理好了，可以关闭的时候，会发送一个FIN报文，然后进入LAST_ACK。等待最后一个应答。
让客户端收到服务器FIN报文，就进入TIME_WAIT状态了，随后发送最后一个ACK报文，然后close。
客户端再等待2msl后也自己主动关闭。而只有主动关闭的情况下，才会有TIME_WAIT。
那么为什么四次挥手需要四次呢？
三次握手其实就是在第二次把ACK和SYN两个报文合并成一个发，但是断开的过程可能还有一方需要处理下数据，需要延长点时间，等处理好再发FIN，所以就比三次握手多了一次。
这里还有一个问题，为什么需要TIME_WAIT，然后到close需要2msl的时间呢？
先说下什么是MSL，也就是报文的最长生存时间，超过这个时间的报文就要被丢弃掉。tcp是基于ip的，ip上有个生存时间TTL,是ip报文可以经过的最大路由数量，每经过一个路由就减1，减到0，ip报文就丢弃掉，然后通过ICMP通知源主机，我们的ping也算是经过这个。当然msl和ttl还是有区别的，msl是时间，ttl是路由数量，msl也是大于等于ttl的。在linux中，2msl默认是60秒。
前文也说了，只有主动发起断开连接的进程才会有time wait状态。time wait+2msl有两个原因：
1.防止旧连接的数据包
像这个seq 301的包，如果因为网络的原因被延迟了，而没有time wait或者很短，那么连接断开后，又建立新的连接，这个时候这个包到了，可能就导致数据紊乱了。而2msl可以保证两个方向的包在断开前丢弃掉。
2.保证正确的断开连接
2msl的时间也是保证第四个报文的ack可以被被动关闭方接收到。
如图，假设time wait比较短或者没有，当最后的ack报文丢失的时候。客户端已经close了，而服务器一直处于last ack的状态。这样连接就不能正常断开了。而如果有time wait +2msl这个情况就可以避免。假设服务器没有收到最后一个ack报文，服务器会重发FIN等待客户端的ack。
这样就可以保证不会出现一端断开，另外一端没有断开的情况了。
有时候我们在服务器上会看到很多time wait。time wait一般就是服务器主动发起的断开请求才会产生的状态。所以time wait过多，第一个是系统资源会大量消耗，还有是端口如果占的太多，会导致没办法创建新连接。这个时候可以把linux的net.ipv4.tcp_tw_reuse开启，置为1，可以复用time wait超过1秒的连接。
这边再说说tcp的保活机制。也就是怎么长期维持客户端和服务端的连接。
在一个时间段内，如果没有连接等相关活动，tcp的保活机制会定期发探测报文，如果连续几个探测报文就没有回应，就将错误信息报告给系统，系统通知上层应用。
在 Linux 内核可以有对应的参数可以设置保活时间、保活探测的次数、保活探测的时间间隔，以下都为
默认值：
tcp_keepalive_time=7200：表示保活时间是 7200 秒（2⼩时），也就 2 小时内如果没有任何连接
相关的活动，则会启动保活机制
tcp_keepalive_intvl=75：表示每次检测间隔 75 秒；
tcp_keepalive_probes=9：表示检测 9 次无响应，认为对⽅方是不不可达的，从⽽而中断本次的连接。
也就是说在 Linux 系统中，最少需要经过 2 小时 11 分 15 秒才可以发现一个“死亡”连接。
当然这个时间也可以自己配置。
❺ 求教tcp短连接断开后如何重连的问题
理想状态下，一个 TCP 连接可以被长期保持。然而，在实际应用中，客户端或服务器端上维持的一个看似正常的 TCP 连接可能已经断连。TCP 连接主要受到两个方面的影响而导致断连：网络中间节点和客户端 / 服务器节点参与通信的两方节点？
在
实际网络应用中，两个主机之间的通信往往需要穿越多个中间节点，例如路由器、网关、防火墙等。因此，两个主机之间 TCP
连接的保持同样会受到中间节点的影响，尤其是会受到防火墙（软件或硬件防火墙）的限制。防火墙是一种装置，有多种不同的实现方式（软件实现、硬件设备实现
或是软硬件相结合实现），它需要依据一系列规则对进出的信息流进行扫描，并允许安全（符合规则）的信息交互、阻止不安全（违反规则）的信息交互。防火墙的
工作特性决定了要维护一个网络连接就需要耗费较多的资源，并且企业防火墙常常位于企业网络的出入口，长时间维护非活跃的 TCP
连接必将导致网络性能的下降。因此，大部分防火墙默认会关闭长时间处于非活跃状态的连接而导致 TCP
连接断连。类似的，如果中间节点异常导致来自客户端关闭连接的请求无法传递到服务器端，也将导致服务器端的相应连接发生断连。
❻ TCP/IP断开
服务器重启后，客户端处于半打开状态，也就是FIN-WAIT-1状态。客户端觉得连接还是正常的，但是服务端丢失了连接的所有信息。这种情况下，客户端发送请求给服务端，服务端无法处理，就会出现超时。当然，客户端会尝试重新发送，但是重试次数是有限的，重试次数由tcp_orphan_retries参数控制。经过几轮重试后，如果一直没有收到服务端的ACK，就会关闭连接。
由于FIN-WAIT-1状态是服务端主动断开客户端的连接导致的，此时可以减小重试次数，尽快让客户端请求超时，超时后连接会自动关闭。
❼ 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连接的关系
❽ 正在尝试写一个TCP服务器，为什么我的客户端怎样都连接不上
1）如果是宽带本身的问题，首先直接联接宽带网线测试，如果是宽带的问题，联系宽带客服解决。
2）如果是路由器的问题，如果原来可以用，暂时不能用了，我自己的实践是一个是断掉路由器的电源在插上，等会看看。在有就是恢复出厂设置，从新设置就可以用了（这是在物理连接正确的前提下，有时是路由器寻IP地址慢或失败引起的，并不是说路由器坏了）。
如果总是不能解决，建议给路由器的客服打电话，他们有电话在线指导，我遇到自己不能解决的问题，咨询他们给的建议是很有用的，他们会针对你的设置或操作给出正确建议的。
3）如果关闭了无线开关开启就是了，如果是用软件连接的无线，软件不好用又经常出问题是很正常的，没有更好的方法，用路由器吧。另外就是网卡驱动没有或不合适引起的，网线接口或网线是不是有问题等。
4）如果是系统问题引起的，建议还原系统或重装。
❾ 为什么我写的modbus tcp通信协议服务器一断，在起来连不上客户端
可能是你没有处理好关闭连接，服务器程序如果出错退出，或者退出时没进行断开客户端的操作，会造成客户端不知道服务器已停止工作，而继续保持虚连接，造成重连失效。
建议完善服务器程序设计，在服务器退出前，增加关闭所有客户端连接，并收回socket的操作。
❿ 传输层TCP协议连接的建立和断开
什么是TCP呢？
由三个单词组成的Transport Control Protocol，字面理解是传输控制协议，可以理解为比特同学要想在网络泳池里游泳，那么他必须学习传输层控制技能，并且要掌握相应的动作——协议，他才能在畅游世界网络这个超大型游泳池。
TCP：一个传输层协议，提供Host-To-Host的可靠传输，支持全双工，是一个面向连接的协议。
TCP工作在传输层，它的上层是应用层，应用就是人们常用的微信、抖音、王者荣耀等服务工作的协议。两台不同的设备使用微信聊天，发送语音，需要实现Host-To-Host的数据通信，那么就可以直接调用TCP协议进行。
调用TCP通信时需要指定通信的端口，不同的端口对应不同应用，不同IP对应不同的主机，也就是不同的设备。这就涉及到网络地址—— IP地址 ，工作在网络层，当然TCP层只负责把对应的IP地址和端口传给网络层即可，具体业务由网络层来实现。
互联网层，即Network Layer ，提供地址和地址间的通信，只关注地址到地址Address-To-Address间通信，具体设备间通信由数据链路层实现，数据链路层关注MAC地址间通信，具体的物理设备，传输介质由物理层负责。
以上就是TCP/IP协议常用的层级分割，最终目的就是为Host-To-Host服务，实现应用到应用的通信服务。
什么是连接和会话呢？
连接事需要通信双方相互配合来实现的，是双方达成的一种即时的状态约定，保证通信双方都在线，都有能力为接下来的数据传输做出尽快的响应，我们称之为 连接 。
连接是网络行为状态的记录，既然连接需要双方共同努力，那么就需要双方都有一个对象来记忆当前传输的数据类型，对方的端口、已经传输了多少，效率怎么样等等一些关注点。
那么与之相关联的另一个名词 会话（Session） ，是什么意思呢，会话是应用的行为。大家每次用微信聊天时都会有一个窗口，用来发送信息，你来我往，这个窗口中会有很多条信息，我们称之为会话，当我们在会话进行中，连接一定是在通信状态的。聊一会，累了，退出微信了，但是一般我们不会删除我们的会话内容，这时会话还在，但是连接已经中断。
双工/单工问题
想想自己理解的是什么？
单工：任何时间，数据只能单向发送，单工至少需要一条线路
半全双工：某一时候可以双向发送数据，至少需要一条线路
全双工：任何时刻都可以双向发送数据，大于一条线路
这里线路不一定真实存在物理线路，可能采用模拟的形式实现
TCP是一个全双工协议，数据任何时刻都可以双向发送 ，这说明服务器和客户端可以根据需要选择任意时刻发送和接收信息，所以呢都可以被称为主机（Host）
可靠性的定义
TCP可以提供可靠性，那么可靠性具体的实现方式是什么呢？
可靠性指数据无损传输 。发送主机按照顺序发送数据，数据通过网络传输，收不同网络条件限制，数据不会按照发送时的顺序到达接收方，这时我们就需要一种算法来保证接收方可以还原出发送方的顺序。这里还有一个概念叫 多播 ，发送方同时发送给多个接收方信息，如果接收方中有一个接收到了这条信息，我们的可靠性就必须保证其他接收方也必须接收到相同的信息，这里我们不讨论多播。
TCP的握手和挥手
TCP是一个面向连接的连接的协议， 握手 是建立连接的过程， 挥手 是断开连接的过程。
TCP的基本操作
以上三种操作以后，另一方必须立即给发起方返回一个 ACK（Ackknowledgement） ，这是TCP保证可靠性的要求。如果一方不回复发送方ACK，发送方则认为接收方没有收到信息，会重新发送。
建立连接的过程-三次握手
三次握手的形成和TCP要求每次发送方发送信息以后，接收方必须返回ACK确认有直接的关系
上图描述了TCP建立连接的过程，分为6步：
TCP建立连接的过程如上，那么为什么是三次呢？
第二步服务端做准备，因为是首次收到发送数据请求，无需处理，可以立刻进入数据交互状态，所以可以立刻发送给客户端SYN，告诉客户端，我已准备好，所以第三步和第四步可以合并为一次握手——ACK-SYN，然后客户端回应ACK，连接建立完成
以上就是三次握手了
具体在数据交互过程，ACK和SYN等需要用标识位来标记，在实际应用中，我们一般使用1来表示开启，0表示关闭。
那么四次挥手为什么是四次呢，主要是因为，挥手时服务端收到FIN以后，不能马上回复FIN，因为自身还有任务没有处理完，所以上面所说的6步中，第3、4步就不能一起回复，只能先回复ACK，等自身任务处理完毕，才能告诉客户端，我已经准备好，可以关闭连接，这样就需要4次数据交互，如下图：