视频交易类网页,seo怎样优化网站,宝安网站建设zrare,在线营销推广这里写目录标题 TCP头格式有哪些为什么需要TCP#xff0c;TCP工作在哪什么是TCP什么是TCP连接如何确定一个TCP连接TCP和UDP的区别#xff0c;以及场景TCP和UDP能共用一个端口#xff1f;TCP的建立TCP三次握手过程为什么是三次握手、不是两次、四次why每次建立连接#xff0… 这里写目录标题 TCP头格式有哪些为什么需要TCPTCP工作在哪什么是TCP什么是TCP连接如何确定一个TCP连接TCP和UDP的区别以及场景TCP和UDP能共用一个端口TCP的建立TCP三次握手过程为什么是三次握手、不是两次、四次why每次建立连接初始化序列号要求不一样初始化序列号ISN是如何随机产生的IP层会分片whyTCP层还需要MSS第一次握手丢失会发生什么第二次握手丢失了会发生什么第三次握手丢失了会发生什么SYN攻击如何避免半连接队列和全连接队列避免 SYN 攻击方式 TCP连接断开四次挥手过程为什么挥手需要四次第一次挥手丢失会发生什么第二次挥手丢失会发生什么第三次挥手丢失会发生什么第四次挥手丢失会发生什么为什么TIME_WAIT等待时间是2MSL为什么要有TIME_WAIT状态TIME_WAIT 多有什么危害如何优化 TIME_WAIT服务器出现大量TIME_WAIT状态的原因是什么什么场景下服务端会主动断开连接 服务器出现大量 CLOSE_WAIT 状态的原因有哪些 Socket编程什么是SocketTCP和UDP的区别socket()函数的作用bind()函数的作用listen和accept函数的区别connect()函数的作用send()和recv()函数的区别什么是阻塞和非阻塞socket为什么TCP连接需要三次握手和四次挥手TIME_WAIT状态的作用如何优化TIME_WAIT状态 重传机制超时重传快速重传SACK选择性确认D-SACK 滑动窗口发送方的窗口接受方的窗口接收和发送窗口相等吗 流量控制TCP流量控制的主要目标TCP 流量控制的基本原理TCP 流量控制实现的特性TCP流量控制的过程窗口关闭如何解决窗口关闭潜在的死锁问题 拥塞控制为什么需要拥塞控制拥塞窗口和发送窗口有什么关系拥塞控制的控制算法慢启动拥塞避免拥塞发生快速恢复 半连接队列和全连接队列 TCP头格式有哪些 源端口号和目标端口号16位字段用于标识TCP连接的源和目标端口号。序列号Sequence Number32位字段用于标识发送的数据字节流中的第一个字节的序号。确认号Acknowledgment Number32位字段确认收到的字节序号即期望接收的下一个字节的序号。数据偏移4位字段指示TCP头部的长度以32位字为单位。保留、U、A、P、R、S、F这些标志位用于控制TCP连接的状态和行为例如URG紧急指针有效、ACK确认号有效、PSH接收方应尽快将数据交给应用、RST重置连接、SYN建立连接请求、FIN关闭连接。窗口大小Window Size16位字段表示接收方的接收窗口大小用于流量控制。校验和Checksum16位字段用于检测TCP头部和数据是否在传输过程中发生错误。紧急指针Urgent Pointer16位字段仅在URG标志位设置为1时有效用于指示紧急数据的字节偏移。选项可选用于在TCP头部中指定一些附加选项如最大报文段长度MSS等。填充Padding用于确保TCP头部达到指定长度的填充字段
为什么需要TCPTCP工作在哪
IP层不可靠不保证网络包的交付不保证网络包的按序交付也不保证网络包中的数据的完整性。因为 TCP 是一个工作在传输层的可靠数据传输的服务它能确保接收端接收的网络包是无损坏、无间隔、非冗余和按序的。
什么是TCP
TCP 是面向连接的、可靠的、基于字节流的传输层通信协议。
面向连接再进行数据传输之前通信的两端需要建立一个可靠的连接通过三次握手来建立可靠的TCP 可以保证一个报文一定能够到达接收端通过序列号、确认应答和重传等机制来确保数据的可靠传输字节流指的是在TCP连接中数据被视为连续的字节流而不是分割成固定大小的数据块或消息。当应用程序发送数据时TCP会将这些数据拆分成较小的数据块并为每个数据块添加TCP头部信息然后将它们作为字节流发送
什么是TCP连接
建立一个TCP连接是需要客户端与服务端达成上述三个信息共识
Socket用IP地址和端口号组成序列号用来解决乱序问题窗口大小用来做流量控制
TCP连接Transmission Control Protocol connection是计算机网络中的一种通信方式它建立在传输控制协议TCP之上。TCP连接是一种面向连接的通信方式意味着在数据传输之前通信的两端通常是客户端和服务器需要通过一系列握手来建立一个可靠的连接。
如何确定一个TCP连接
源地址、源端口、目的地址、目的端口地址32位在IP头部端口16位在TCP头部
TCP最大连接数客户端IP数*客户端端口数
TCP和UDP的区别以及场景
TCP传输控制协议和UDP用户数据报协议是两种常见的传输层协议它们在网络通信中有着不同的特点和应用场景。
TCP的特点和应用场景
面向连接TCP使用三次握手建立连接确保通信双方建立可靠的连接后再进行数据传输。可靠性TCP保证数据的可靠传输通过序列号、确认应答和重传机制来确保数据的完整性和正确性。有序性TCP会按照发送顺序保证数据包在接收端按序重组避免数据包乱序的情况。流控制和拥塞控制TCP通过流控制和拥塞控制算法来平衡发送和接收数据的速率防止网络拥塞。应用场景TCP适用于对数据完整性和可靠性要求较高的应用如网页浏览、文件传输、电子邮件等。
UDP的特点和应用场景
无连接UDP不需要建立连接直接将数据包发送出去适用于无需建立持久连接的通信场景。不可靠性UDP不保证数据的可靠传输数据包可能丢失、重复、乱序需要应用层自行处理丢失情况。无序性UDP的数据包可能按照发送顺序的不同在接收端乱序到达应用层需要处理乱序的情况。低延迟由于不需要建立连接和拥有较少的控制机制UDP传输具有较低的延迟。应用场景UDP适用于对实时性要求较高的应用如视频直播、在线游戏、音频通话等。在这些场景下实时性更重要而对于数据丢失的情况可以通过应用层的处理来进行容忍或纠正。
分片不同
TCP 的数据大小如果大于 MSS最大分段大小 大小则会在传输层进行分片目标主机收到后也同样在传输层组装 TCP 数据包如果中途丢失了一个分片只需要传输丢失的这个分片。MSS它是TCP协议中的一个参数用于指示在TCP连接中每个数据包的最大有效载荷大小即除去TCP头部后的数据部分大小。UDP 的数据大小如果大于 MTU最大传输单元 大小则会在 IP 层进行分片目标主机收到后在 IP 层组装完数据接着再传给传输层。MTU 它是指在网络通信中能够承载的最大数据包的大小。MTU是以字节为单位来衡量的。
综上所述TCP和UDP各有优势应根据具体应用场景的需求来选择合适的协议。对于重要数据的传输和确保数据可靠性的应用可以选择TCP。而对于实时性要求较高的应用可以选择UDP。
TCP和UDP能共用一个端口
答案可以
**简介回答**端口号的目的主要是为了区分同一个主机不同应用程序的数据包传输层有两个传输协议分别是 TCP 和 UDP在内核中是两个完全独立的软件模块当主机收到数据包后可以在 IP 包头的「协议号」字段知道该数据包是 TCP/UDP所以可以根据这个信息确定送给哪个模块TCP/UDP处理送给 TCP/UDP 模块的报文根据「端口号」确定送给哪个应用程序处理。
**详细回答**在一般情况下TCP和UDP是不能共用一个端口的。TCP和UDP是两种不同的传输层协议它们使用不同的端口来进行通信。每个网络通信应用都使用特定的端口号来与其他应用进行交流。TCP和UDP各自有独立的端口号空间这意味着一个特定的端口号在TCP和UDP之间可以同时存在但它们对应的是不同的应用或服务。例如HTTP通常使用TCP协议在80端口进行通信DNS通常使用UDP协议在53端口进行通信。这意味着在同一时间80端口可能被TCP协议的HTTP使用而53端口可能被UDP协议的DNS使用二者不会相互干扰。然而也有一些特殊情况下某些应用或协议可以同时使用TCP和UDP共享同一个端口。这被称为TCP/UDP多路复用或TCP/UDP Port Sharing。这种情况下应用程序需要负责处理接收到的数据并根据数据包的内容区分使用TCP还是UDP来处理数据。这样的机制通常由应用层协议自行实现而不是由TCP和UDP协议栈提供的默认功能。总的来说大多数情况下TCP和UDP使用独立的端口来避免混淆和冲突。但特定的应用场景下TCP/UDP多路复用可以实现在同一个端口上同时使用TCP和UDP。
TCP的建立
TCP三次握手过程 TCP三次握手是建立TCP连接的过程它用于确保客户端和服务器之间建立可靠的连接。以下是TCP三次握手的过程 第一次握手SYN 客户端向服务器发送一个连接请求报文段其中设置了SYN标志位SYN1。客户端选择一个初始序列号ISNInitial Sequence Number用于后续数据的传输。 第二次握手SYNACK 服务器收到客户端的连接请求后回复一个确认报文段作为回应。服务器在回复的报文段中设置了SYN和ACK标志位SYN1ACK1。服务器也选择一个初始序列号ISN用于后续数据传输并将确认号ACK设置为客户端的初始序列号ISN 1。 第三次握手ACK 客户端收到服务器的确认报文段后向服务器发送一个确认报文段。客户端在这个报文段中设置了ACK标志位ACK1。客户端的确认号ACK被设置为服务器的初始序列号ISN 1表示已收到服务器的回应。
一旦服务器收到客户端的确认报文段TCP连接就建立成功可以开始进行数据传输。在这个过程中客户端和服务器通过交换序列号和确认号来确保彼此能够正确接收数据从而建立可靠的连接。第三次握手是可以携带数据的前两次握手是不可以携带数据的
为什么是三次握手、不是两次、四次
三次握手才可以阻止重复历史连接的初始化主要原因三次握手才可以同步双方的初始序列号三次握手才可以避免资源浪费「两次握手」无法防止历史连接的建立会造成双方资源的浪费也无法可靠的同步双方序列号「四次握手」三次握手就已经理论上最少可靠连接建立所以不需要使用更多的通信次数。 why每次建立连接初始化序列号要求不一样
为了防止历史报文被下一个相同四元组的连接接收主要方面为了安全性防止黑客伪造的相同序列号的 TCP 报文被对方接收
增强安全性 选择不同的初始序列号可以增强安全性。如果每次建立连接时初始序列号都是相同的那么攻击者可以利用这个预测性来发动网络攻击例如TCP序列号预测攻击。通过选择不同的初始序列号可以增加攻击者猜测序列号的难度提高连接的安全性。
防止旧连接的混淆 TCP协议要求当处于TIME_WAIT状态的连接结束后必须经过一段时间的等待才能确保网络上的所有数据包都被丢弃。在此期间如果有新的连接建立并选择了与已结束的旧连接相同的初始序列号可能会导致新连接收到旧连接的数据包从而造成混淆。通过选择不同的初始序列号可以避免这种情况的发生。 初始化序列号ISN是如何随机产生的
起始 ISN 是基于时钟的每 4 微秒 1转一圈要 4.55 个小时RFC793 提到初始化序列号 ISN 随机生成算法ISN M F(localhost, localport, remotehost, remoteport)。
M 是一个计时器这个计时器每隔 4 微秒加 1。F 是一个 Hash 算法根据源 IP、目的 IP、源端口、目的端口生成一个随机数值。要保证 Hash 算法不能被外部轻易推算得出用 MD5 算法是一个比较好的选择。
IP层会分片whyTCP层还需要MSS 如果一个IP分片丢失整个IP报文的所有分片都得重传因为IP层本身没有超时重传机制由传输层TCP来负责超时和重传
当一个TCP分片丢失重发时以MSS
TCP层发现数据超过MSS时会先进行分片然后由它形成的IP包的长度也就不会大于MTU
虽然IP层可以对大于MTU的数据包进行分片但TCP层的MSS最大分段大小参数仍然非常重要因为TCP层的MSS决定了在TCP连接中每个数据包的最大有效载荷大小而这对于TCP连接的性能和效率至关重要。下面解释为什么TCP层需要MSS
1. 避免不必要的分片 TCP层的MSS参数允许TCP在发送数据之前根据网络的MTU选择一个适当的最大有效载荷大小。如果TCP层的数据包大小超过了MTUIP层会对数据包进行分片。分片增加了网络传输的复杂性也可能导致丢失或乱序的问题。通过设置适当的MSSTCP可以尽量避免数据包被分片提高数据传输的效率和可靠性。
2. 控制拥塞窗口 TCP使用拥塞控制算法来避免网络拥塞。MSS是拥塞窗口的一个重要参数。拥塞窗口决定了TCP可以发送的未确认数据量通过调整MSS可以控制拥塞窗口的大小从而适应网络的拥塞状况防止过多的数据注入导致网络拥塞。
3. 保持连接的可靠性 TCP层的MSS也与TCP连接的可靠性密切相关。较大的MSS可以减少连接的握手次数和数据包数量从而降低连接建立和维护的开销提高连接的可靠性。
总的来说虽然IP层可以进行分片但TCP层的MSS仍然非常重要它可以避免不必要的分片控制拥塞窗口提高连接的可靠性从而优化TCP连接的性能和效率。通过合理设置MSSTCP可以更好地适应不同网络环境实现高效、可靠的数据传输。
第一次握手丢失会发生什么
客户端就会触发「超时重传」机制重传 SYN 报文而且重传的 SYN 报文的序列号都是一样的。不同操作系统超时时间不同有的1秒有的3秒Linux里客户端SYN报文最大重传次数由tcp_syn_retries参数控制默认值5。每次超时的时间是上一次的 2 倍
第二次握手丢失了会发生什么
客户端就会触发超时重传机制重传 SYN 报文。服务端这边会触发超时重传机制重传 SYN-ACK 报文。在 Linux 下SYN-ACK 报文的最大重传次数由 tcp_synack_retries内核参数决定默认值是 5。
第三次握手丢失了会发生什么
服务端就会触发超时重传机制重传 SYN-ACK 报文直到收到第三次握手或者达到最大重传次数。ACK 报文是不会有重传的当 ACK 丢失了就由对方重传对应的报文。
SYN攻击如何避免
半连接队列和全连接队列 正常流程
当服务端接收到客户端的 SYN 报文时会创建一个半连接的对象然后将其加入到内核的「 SYN 队列」接着发送 SYN ACK 给客户端等待客户端回应 ACK 报文服务端接收到 ACK 报文后从「 SYN 队列」取出一个半连接对象然后创建一个新的连接对象放入到「 Accept 队列」应用通过调用 accpet() socket 接口从「 Accept 队列」取出连接对象。
不管是半连接队列还是全连接队列都有最大长度限制超过限制时默认情况都会丢弃报文。
SYN 攻击方式最直接的表现就会把 TCP 半连接队列打满这样当 TCP 半连接队列满了后续再在收到 SYN 报文就会丢弃导致客户端无法和服务端建立连接。
避免 SYN 攻击方式
可以有以下四种方法
调大 netdev_max_backlog当网卡接收数据包的速度大于内核处理的速度时会有一个队列保存这些数据包队列长度默认值1000增大 TCP 半连接队列开启 tcp_syncookies减少 SYNACK 重传次数
TCP连接断开
四次挥手过程 TCP四次挥手是终止TCP连接的过程用于断开客户端和服务器之间的连接。以下是TCP四次挥手的过程 第一次挥手FIN 客户端向服务器发送一个连接关闭请求其中设置了FIN标志位FIN1。客户端不再发送数据但仍可以接收服务器发送的数据。 第二次挥手ACK 服务器收到客户端的连接关闭请求后回复一个确认报文段作为回应。服务器在回复的报文段中设置了ACK标志位ACK1确认客户端的关闭请求。服务器可能仍有数据要发送给客户端所以服务器的FIN标志位尚未设置。 第三次挥手FIN 服务器继续发送数据给客户端在数据发送完毕后将自己的连接关闭请求发送给客户端。服务器设置FIN标志位FIN1表示服务器准备关闭连接。 第四次挥手ACK 客户端收到服务器的连接关闭请求后回复一个确认报文段作为回应。客户端在回复的报文段中设置了ACK标志位ACK1确认服务器的关闭请求。至此TCP连接正式关闭。
注意在进行四次挥手过程中客户端和服务器都可以在最后一次挥手前发送数据因为FIN标志位只表示自己不再发送数据而并不表示对方不再发送数据。因此四次挥手可能是FIN-WAIT-1“FIN-WAIT-2”TIME-WAIT等状态之间的过程。等待一段时间后处于TIME-WAIT状态的一方会关闭连接完成整个四次挥手过程。
为什么挥手需要四次
关闭连接时客户端向服务端发送 FIN 时仅仅表示客户端不再发送数据了但是还能接收数据。服务端收到客户端的 FIN 报文时先回一个 ACK 应答报文而服务端可能还有数据需要处理和发送等服务端不再发送数据时才发送 FIN 报文给客户端来表示同意现在关闭连接。
从上面过程可知服务端通常需要等待完成数据的发送和处理所以服务端的 ACK 和 FIN 一般都会分开发送因此是需要四次挥手。特定情况下四次挥手是可以变成三次挥手的
第一次挥手丢失会发生什么
会触发超时重传机制客户端重传 FIN 报文重发次数由 tcp_orphan_retries 参数控制。
第二次挥手丢失会发生什么
客户端就会触发超时重传机制重传 FIN 报文直到收到服务端的第二次挥手或者达到最大的重传次数
第三次挥手丢失会发生什么
服务端就会重发 FIN 报文重发次数仍然由 tcp_orphan_retries 参数控制这与客户端重发 FIN 报文的重传次数控制方式是一样的FIN_WAIT_2状态默认60秒有tcp_fin_timeout参数控制
第四次挥手丢失会发生什么
如果第四次挥手的 ACK 报文没有到达服务端服务端就会重发 FIN 报文重发次数仍然由前面介绍过的 tcp_orphan_retries 参数控制
为什么TIME_WAIT等待时间是2MSL
MSL报文最大生存时间
TTL经过路由跳数
TTL 的值一般是 64Linux 将 MSL 设置为 30 秒意味着 Linux 认为数据报文经过 64 个路由器的时间不会超过 30 秒如果超过了就认为报文已经消失在网络中了。
网络中可能存在来自发送方的数据包当这些发送方的数据包被接收方处理后又会向对方发送响应所以一来一回需要等待 2 倍的时间TIME_WAIT等待时间为2倍的MSLMaximum Segment Lifetime这个值是为了确保在网络中所有可能的冗余数据包都已经被丢弃从而保证TCP连接的可靠关闭。
为什么要有TIME_WAIT状态
防止历史连接中的数据被后面相同四元组的连接错误的接收保证「被动关闭连接」的一方能被正确的关闭 服务端在关闭连接之前发送的 SEQ 301 报文被网络延迟了。接着服务端以相同的四元组重新打开了新连接前面被延迟的 SEQ 301 这时抵达了客户端而且该数据报文的序列号刚好在客户端接收窗口内因此客户端会正常接收这个数据报文但是这个数据报文是上一个连接残留下来的这样就产生数据错乱等严重的问题。
TIME_WAIT 多有什么危害
第一是占用系统资源比如文件描述符、内存资源、CPU 资源、线程资源等第二是占用端口资源端口资源也是有限的一般可以开启的端口为 3276861000也可以通过 net.ipv4.ip_local_port_range参数指定范围。如果客户端主动发起关闭连接方的 TIME_WAIT 状态过多占满了所有端口资源那么就无法对「目的 IP 目的 PORT」都一样的服务端发起连接了但是被使用的端口还是可以继续对另外一个服务端发起连接的如果服务端主动发起关闭连接方的 TIME_WAIT 状态过多并不会导致端口资源受限因为服务端只监听一个端口而且由于一个四元组唯一确定一个 TCP 连接因此理论上服务端可以建立很多连接但是 TCP 连接过多会占用系统资源比如文件描述符、内存资源、CPU 资源、线程资源等
如何优化 TIME_WAIT 打开 net.ipv4.tcp_tw_reuse 和 net.ipv4.tcp_timestamps 选项tcp_tw_reuse 功能只能用客户端连接发起方因为开启了该功能在调用 connect() 函数时内核会随机找一个 time_wait 状态超过 1 秒的连接给新的连接复用使用这个选项还有一个前提需要打开对 TCP 时间戳的支持 net.ipv4.tcp_max_tw_buckets这个值默认为 18000当系统中处于 TIME_WAIT 的连接一旦超过这个值时系统就会将后面的 TIME_WAIT 连接状态重置这个方法比较暴力 程序中使用 SO_LINGER 应用强制使用 RST 关闭。我们可以通过设置 socket 选项来设置调用 close 关闭连接行为
优化TIME_WAIT状态主要是通过调整TCP连接的参数来减少或优化TIME_WAIT等待时间以减少资源占用和提高系统性能。以下是一些常见的优化方法 减少TIME_WAIT等待时间 在Linux系统中可以通过修改系统的TCP参数来减少TIME_WAIT等待时间。例如可以通过修改tcp_fin_timeout参数来减少TIME_WAIT状态的持续时间。这个参数控制在TCP连接关闭后套接字保持在TIME_WAIT状态的时间默认值是60秒。可以根据实际情况适当降低这个值例如设置为30秒。 重用端口 可以通过设置SO_REUSEADDR套接字选项来允许重用处于TIME_WAIT状态的端口。这样可以避免新的连接被拒绝从而提高系统的连接处理能力。在Go语言中可以通过设置ReuseAddr字段为true来实现端口重用
listener, err : net.Listen(tcp, localhost:8080)
if err ! nil {// 错误处理
}listener.(*net.TCPListener).SetReuseAddr(true)快速回收 在Linux系统中可以通过设置tcp_tw_recycle参数来开启快速回收模式。快速回收模式允许将处于TIME_WAIT状态的套接字快速回收从而释放系统资源。但需要注意的是快速回收模式可能会导致一些问题因此在开启前需要仔细评估网络环境和应用需求。
# 设置快速回收模式
sudo sysctl -w net.ipv4.tcp_tw_recycle1减少短暂连接 尽量减少短暂连接的创建短暂连接容易产生大量TIME_WAIT状态增加系统负担。可以通过连接池或连接复用的方式来优化短暂连接的管理。
需要注意的是优化TIME_WAIT状态需要根据具体的系统和网络环境进行调整并且某些优化方法可能会带来潜在的风险。因此在进行优化前应该仔细评估系统的性能和稳定性需求并根据实际情况进行调整。
服务器出现大量TIME_WAIT状态的原因是什么
什么场景下服务端会主动断开连接
第一个场景HTTP 没有使用长连接第二个场景HTTP 长连接超时第三个场景HTTP 长连接的请求数量达到上限
服务器出现大量TIME_WAIT状态的主要原因是短暂连接的频繁建立和关闭通常在高并发的网络环境中或者存在大量短连接的场景下会出现这种情况。以下是一些导致服务器大量TIME_WAIT状态的常见原因 高并发连接 当服务器面对大量并发连接请求时每个连接建立后在关闭时会进入TIME_WAIT状态。如果连接的频率很高TIME_WAIT状态的连接数量就会迅速增加。 短暂连接 一些应用或协议如HTTP/1.0特点是在每个请求完成后立即关闭连接导致大量短暂连接产生。这些短暂连接会在关闭后进入TIME_WAIT状态从而积累大量TIME_WAIT连接。 连接重用不当 如果服务器没有正确地重用连接而是频繁地创建新的连接就会导致大量TIME_WAIT状态的连接堆积。在高并发场景下应尽量复用现有连接避免频繁创建和关闭连接。 服务器性能不足 当服务器的性能较低或网络负载很高时处理连接的速度可能跟不上连接的建立和关闭速度导致连接在TIME_WAIT状态停留的时间较长。 客户端异常 如果客户端异常地关闭连接而没有经过正常的四次挥手过程服务器可能会出现大量处于TIME_WAIT状态的连接因为服务器没有收到客户端的确认。
为了解决大量TIME_WAIT状态的问题可以考虑以下方法
优化服务器性能提高服务器的处理能力和吞吐量以便更快地处理连接的建立和关闭。合理地设置TCP参数如tcp_tw_reuse和tcp_tw_recycle等根据实际情况减少TIME_WAIT等待时间。优化应用程序逻辑尽量复用连接减少短暂连接的创建和关闭。使用连接池或连接复用等技术合理管理连接资源。
服务器出现大量 CLOSE_WAIT 状态的原因有哪些
当服务端出现大量 CLOSE_WAIT 状态的连接的时候说明服务端的程序没有调用 close 函数关闭连接。当服务端出现大量 CLOSE_WAIT 状态的连接的时候通常都是代码的问题这时候我们需要针对具体的代码一步一步的进行排查和定位主要分析的方向就是服务端为什么没有调用 close
Socket编程
Socket编程是一种用于在计算机网络中实现通信的编程方法。它是基于TCP/IP协议栈的一种编程接口允许程序通过网络在不同计算机之间进行数据传输和通信。
在Socket编程中程序可以通过创建Socket对象来建立网络连接。Socket对象提供了一组函数通常是系统调用来进行数据的发送和接收。通过Socket编程程序可以实现客户端和服务器之间的通信实现数据的传输和交换。
Socket编程通常使用两种类型的Socket 流式SocketStream Socket 使用TCP协议来进行数据传输提供可靠的、面向连接的通信。流式Socket适用于需要可靠数据传输的场景如HTTP、FTP等。 数据报SocketDatagram Socket 使用UDP协议来进行数据传输提供不可靠的、无连接的通信。数据报Socket适用于对数据传输时延要求较低但可靠性要求较低的场景如视频流传输、实时游戏等。
Socket编程常用于网络编程和分布式系统中它允许不同计算机上的应用程序之间进行通信和数据交换实现了跨网络的数据传输和通信功能。在不同编程语言中都提供了对Socket编程的支持例如C、C、Python、Java等。 服务端和客户端初始化 socket得到文件描述符服务端调用 bind将 socket 绑定在指定的 IP 地址和端口;服务端调用 listen进行监听服务端调用 accept等待客户端连接客户端调用 connect向服务端的地址和端口发起连接请求服务端 accept 返回用于传输的 socket 的文件描述符客户端调用 write 写入数据服务端调用 read 读取数据客户端断开连接时会调用 close那么服务端 read 读取数据的时候就会读取到了 EOF待处理完数据后服务端调用 close表示连接关闭。
当涉及到socket编程的面试题时面试官可能会问一系列问题来评估候选人的网络编程能力。以下是一些常见的socket编程面试题及其答案
什么是Socket
答案Socket是一种用于实现网络通信的编程接口它允许进程程序通过网络进行数据传输和通信。Socket提供了一种机制使得不同主机上的进程能够建立连接并进行数据交换。
TCP和UDP的区别
答案TCP传输控制协议是一种面向连接的可靠协议它通过三次握手来建立连接并使用确认和重传机制来确保数据可靠传输。UDP用户数据报协议是一种无连接的不可靠协议它不进行连接建立和断开直接将数据发送给目标不保证数据的可靠传输。
socket()函数的作用
答案socket()函数用于创建套接字返回一个用于网络通信的文件描述符。它需要指定通信协议如TCP或UDP和地址族IPv4或IPv6。
bind()函数的作用
答案bind()函数用于将套接字与特定的IP地址和端口号绑定使其能够在网络上被其他进程找到。
listen和accept函数的区别
答案listen()函数用于服务器端将套接字设置为监听模式等待客户端的连接请求。accept()函数用于服务器端接受客户端的连接请求创建一个新的套接字用于与客户端通信。
connect()函数的作用
答案connect()函数用于客户端与服务器建立连接发起与服务器的三次握手过程。
send()和recv()函数的区别
答案send()函数用于发送数据recv()函数用于接收数据。send()函数返回发送的字节数recv()函数返回接收的字节数。
什么是阻塞和非阻塞socket
答案阻塞socket在执行读写操作时会阻塞当前进程直到操作完成或出现错误。非阻塞socket在执行读写操作时不会阻塞当前进程而是立即返回结果。
为什么TCP连接需要三次握手和四次挥手
答案三次握手用于确保客户端和服务器之间建立可靠的连接。四次挥手用于安全地关闭连接确保双方都能确认对方的关闭意图并避免旧连接的混淆。
TIME_WAIT状态的作用
答案TIME_WAIT状态用于确保在网络中所有可能的冗余数据包都已经被丢弃从而保证TCP连接的可靠关闭。
如何优化TIME_WAIT状态
答案可以通过减少TIME_WAIT等待时间、重用端口、设置快速回收模式等方法来优化TIME_WAIT状态。
这些问题涵盖了socket编程的一些基本概念、函数调用和网络通信流程。面试时理解这些问题的答案并能够清晰地解释socket编程的原理和用法将有助于展示你的网络编程能力和理解水平。
重传机制
超时重传
发送数据时会设定一个定时器当超过指定的时间后没有收到对方的ACK确认应答报文就会重发数据
超时重传的情况
数据包丢失确认应答丢失 RTT是数据发送时刻到接受到确认的时刻的差值也就是包的往返时间
超时重传时间是以 RTO Retransmission Timeout 超时重传时间表示超时重传时间 RTO 的值应该略大于报文往返 RTT 的值
超时时间 RTO 较大时重发就慢丢了老半天才重发没有效率性能差当超时时间 RTO 较小时会导致可能并没有丢就重发于是重发的就快会增加网络拥塞导致更多的超时更多的超时导致更多的重发。
快速重传
不以时间为驱动而是以数据驱动重传 第一份 Seq1 先送到了于是就 Ack 回 2结果 Seq2 因为某些原因没收到Seq3 到达了于是还是 Ack 回 2后面的 Seq4 和 Seq5 都到了但还是 Ack 回 2因为 Seq2 还是没有收到发送端收到了三个 Ack 2 的确认知道了 Seq2 还没有收到就会在定时器过期之前重传丢失的 Seq2。最后收到了 Seq2此时因为 Seq3Seq4Seq5 都收到了于是 Ack 回 6 。
所以快速重传的工作方式是当收到三个相同的 ACK 报文时会在定时器过期之前重传丢失的报文段。快速重传机制只解决了一个问题就是超时时间的问题但是还有另一个问题就是重传的时候重传一个还是所有。于是后面有了SACK
SACK选择性确认
在TCP头部选项字段里加一个SACK的东西他可以将已收到的数据的信息发送给发送方这样发送方就知道哪些数据收到了哪些没有收到就可以重传丢失的数据
D-SACK
其主要使用了 SACK 来告诉「发送方」有哪些数据被重复接收了
好处
可以让「发送方」知道是发出去的包丢了还是接收方回应的 ACK 包丢了;可以知道是不是「发送方」的数据包被网络延迟了;可以知道网络中是不是把「发送方」的数据包给复制了;
滑动窗口
窗口大小指无需等待确认应答而可以继续发送数据的最大值
TCP头部有个字段叫Window也就是窗口的大小这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据而不会导致接收端处理不过来通常窗口的大小是由接受方的窗口大小决定的。
发送方的窗口 #1 是已发送并收到 ACK确认的数据1~31 字节#2 是已发送但未收到 ACK确认的数据32~45 字节#3 是未发送但总大小在接收方处理范围内接收方还有空间46~51字节#4 是未发送但总大小超过接收方处理范围接收方没有空间52字节以后
TCP滑动窗口方案使用三个指针来跟踪四个传输类别中的每个类别中的字节。其中两个指针是绝对指针指确定的序列号一个是相对指针需要做偏移 SND.WND表示发送窗口的大小大小是由接收方指定的SND.UNASend Unacknoleged是一个绝对指针它指向的是已发送但未收到确认的第一个字节的序列号也就是 #2 的第一个字节SND.NXT也是一个绝对指针它指向未发送但可发送范围的第一个字节的序列号也就是 #3 的第一个字节指向 #4 的第一个字节是个相对指针它需要 SND.UNA 指针加上 SND.WND 大小的偏移量就可以指向 #4 的第一个字节了
那么可用窗口大小的计算就可以是可用窗口大小 SND.WND -SND.NXT - SND.UNA
接受方的窗口
#1 #2 是已成功接收并确认的数据等待应用进程读取#3 是未收到数据但可以接收的数据#4 未收到数据并不可以接收的数据 接收和发送窗口相等吗
并不是完全相等接收窗口的大小是约等于发送窗口的大小的。
因为滑动窗口并不是一成不变的。比如当接收方的应用进程读取数据的速度非常快的话这样的话接收窗口可以很快的就空缺出来。那么新的接收窗口大小是通过 TCP 报文中的 Windows 字段来告诉发送方。那么这个传输过程是存在时延的所以接收窗口和发送窗口是约等于的关系。
流量控制
TCP 提供一种机制可以让「发送方」根据「接收方」的实际接收能力控制发送的数据量这就是所谓的流量控制。
TCP 流量控制是指通过一系列的机制来确保发送方与接收方之间的数据传输速率适应接收方的处理能力以防止过多的数据发送导致接收方无法及时处理而发生数据丢失或网络拥塞的情况。
TCP流量控制的主要目标
防止数据丢失和拥塞如果发送方一次性发送大量数据可能会导致网络拥塞数据丢失或延迟增加。适应接收方速率接收方可能处理数据的速度较慢流量控制可以使发送方的速率适应接收方的处理能力。
TCP 流量控制的主要机制是通过滑动窗口Sliding Window和确认机制来实现的。
TCP 流量控制的基本原理
滑动窗口Sliding Window 发送方和接收方之间维护一个滑动窗口该窗口指示了接收方当前能够接受的数据量。发送方根据接收方报告的窗口大小来动态调整发送数据的量以保证不会超过接收方的处理能力。确认机制 接收方会周期性地向发送方发送确认ACK信息表明接收方成功接收了某个特定序号的数据。发送方收到确认后会将对应的数据序号从发送窗口中移除从而允许发送新的数据。
TCP 流量控制实现的特性
滑动窗口大小调整 接收方可以根据自身的处理能力和缓冲区情况来动态调整窗口大小。如果接收方的缓冲区还有空间窗口会增大允许发送更多数据如果缓冲区满了窗口会减小限制发送数据的速率。慢启动和拥塞避免 TCP 在建立连接时采用慢启动算法初始窗口较小然后逐渐增加发送窗口以便探测网络的拥塞情况。一旦网络出现拥塞TCP 会进入拥塞避免状态通过线性增加发送窗口来稳定网络拥塞情况。超时重传 如果发送方没有在一定时间内收到接收方的确认就会认为数据丢失触发超时重传机制重新发送数据。这也有助于控制网络拥塞情况。
TCP流量控制的过程
发送方发送数据段给接收方。接收方接收数据并发送确认。发送方根据接收方发送的确认来确定接收窗口的大小确保发送数据的数量不会超过接收方的处理能力。发送方还根据拥塞窗口的大小来控制发送速率以避免网络拥塞。
总之TCP 流量控制确保了在发送方和接收方之间的数据传输速率匹配从而保证了可靠的数据传输避免了数据丢失和网络拥塞问题。
窗口关闭
如果窗口大小为 0 时就会阻止发送方给接收方传递数据直到窗口变为非 0 为止这就是窗口关闭。
那么当发生窗口关闭时接收方处理完数据后会向发送方通告一个窗口非 0 的 ACK 报文如果这个通告窗口的 ACK 报文在网络中丢失了那麻烦就大了。这会导致发送方一直等待接收方的非 0 窗口通知接收方也一直等待发送方的数据如不采取措施这种相互等待的过程会造成了死锁的现象。
如何解决窗口关闭潜在的死锁问题
为了解决这个问题TCP 为每个连接设有一个持续定时器只要 TCP 连接一方收到对方的零窗口通知就启动持续计时器。如果持续计时器超时就会发送窗口探测 ( Window probe ) 报文而对方在确认这个探测报文时给出自己现在的接收窗口大小。
如果接收窗口仍然为 0那么收到这个报文的一方就会重新启动持续计时器如果接收窗口不是 0那么死锁的局面就可以被打破了。
窗口探测的次数一般为 3 次每次大约 30-60 秒不同的实现可能会不一样。如果 3 次过后接收窗口还是 0 的话有的 TCP 实现就会发 RST 报文来中断连接。
拥塞控制
为什么需要拥塞控制
尽管TCP已经引入了流量控制机制来确保发送方不会以过快的速率向接收方发送数据但流量控制仅仅关注于发送方和接收方之间的数据传输。然而网络中的其他因素如网络拥塞、延迟、丢包等问题可能会影响整体的网络性能和吞吐量。这就是为什么TCP还需要引入拥塞控制机制的原因。
拥塞窗口和发送窗口有什么关系
拥塞窗口 cwnd是发送方维护的一个的状态变量它会根据网络的拥塞程度动态变化的。
我们在前面提到过发送窗口 swnd 和接收窗口 rwnd 是约等于的关系那么由于加入了拥塞窗口的概念后此时发送窗口的值是swnd min(cwnd, rwnd)也就是拥塞窗口和接收窗口中的最小值。
拥塞窗口 cwnd 变化的规则
只要网络中没有出现拥塞cwnd 就会增大但网络中出现了拥塞cwnd 就减少
只要「发送方」没有在规定时间内接收到 ACK 应答报文当发生了超时重传就会认为网络出了拥塞
拥塞控制的控制算法
慢启动
TCP刚开始建立连接一点一点发送数据包当发送方每收到一个ACK拥塞控制cwnd的大小就会加1
有一个叫慢启动门限 ssthresh slow start threshold状态变量。
当 cwnd ssthresh 时使用慢启动算法。当 cwnd ssthresh 时就会使用「拥塞避免算法」。
拥塞避免
一般来说 ssthresh 的大小是 65535 字节。
那么进入拥塞避免算法后它的规则是每当收到一个 ACK 时cwnd 增加 1/cwnd。 我们可以发现拥塞避免算法就是将原本慢启动算法的指数增长变成了线性增长还是增长阶段但是增长速度缓慢了一些。就这么一直增长着后网络就会慢慢进入了拥塞的状况了于是就会出现丢包现象这时就需要对丢失的数据包进行重传。当触发了重传机制也就进入了「拥塞发生算法」。
拥塞发生
当发生了「超时重传」则就会使用拥塞发生算法。这个时候ssthresh 和 cwnd 的值会发生变化
ssthresh 设为 cwnd/2cwnd 重置为 1 是恢复为 cwnd 初始化值我这里假定 cwnd 初始化值 1
当发生了「快速重传」则就会使用拥塞发生算法。这个时候ssthresh 和 cwnd 的值会发生变化
cwnd cwnd/2 也就是设置为原来的一半;ssthresh cwnd;进入快速恢复算法
快速恢复
进入快速恢复算法如下
拥塞窗口 cwnd ssthresh 3 3 的意思是确认有 3 个数据包被收到了重传丢失的数据包如果再收到重复的 ACK那么 cwnd 增加 1如果收到新数据的 ACK 后把 cwnd 设置为第一步中的 ssthresh 的值原因是该 ACK 确认了新的数据说明从 duplicated ACK 时的数据都已收到该恢复过程已经结束可以回到恢复之前的状态了也即再次进入拥塞避免状态 半连接队列和全连接队列
在理解TCP半连接队列SYN队列和全连接队列Accept队列之前让我们先了解TCP的三次握手过程 客户端发送SYN同步 客户端向服务器发送一个SYN包表示客户端想要建立连接。 服务器发送SYN ACK 服务器收到客户端的SYN包后会发送一个带有ACK确认号的SYN包作为响应表示接受连接请求并准备好建立连接。 客户端发送ACK 客户端收到服务器的SYN ACK包后发送一个ACK包表示确认服务器的响应。此时连接建立完成。
现在我们可以来看看半连接队列和全连接队列 半连接队列SYN队列 在TCP的三次握手过程中当服务器发送了SYN ACK包后它会等待客户端发送最终的ACK包以完成连接的建立。在这个等待期间服务器将客户端的连接请求即半连接放入半连接队列等待客户端的最终确认。半连接队列的大小通常是有限的操作系统根据资源和配置来决定。 全连接队列Accept队列 一旦连接的三次握手完成服务器将连接从半连接队列移至全连接队列。全连接队列中的连接已经建立并且可以开始进行数据传输。服务器将按顺序从全连接队列中选择连接并分配资源来处理这些连接。
总结起来半连接队列SYN队列用于存放已经发送了SYN请求但尚未完成三次握手的连接而全连接队列Accept队列则存放已经完成三次握手的连接等待服务器分配资源来处理。这些队列在TCP服务器中起着重要的作用帮助管理并发连接并维护网络性能。
