当前位置： 首页 > news >正文

门户网站开发 南宁,wordpress 自适应设备,企查查官网登录,科技有限公司属于什么行业网络协议常见问题 OSI#xff08;Open Systems Interconnection#xff09;模型OSI 封装 TCP/IP协议栈IP数据报的报头TCP头格式UDP头格式TCP (3-way shake)三次握手建立连接#xff1a;为什么三次握手才可以初始化 Socket、序列号和窗口大小并建立 TCP 连接。每次建立TCP连接… 网络协议常见问题 OSIOpen Systems Interconnection模型OSI 封装 TCP/IP协议栈IP数据报的报头TCP头格式UDP头格式TCP (3-way shake)三次握手建立连接为什么三次握手才可以初始化 Socket、序列号和窗口大小并建立 TCP 连接。每次建立TCP连接时初始化的序列号都要求不一样TCP四次挥手断开TCP连接中客户端和服务器之间操作TCP如何实现可靠传输TCP 流量控制、拥塞控制TCP和UDP的区别TCP粘包问题TCP重置技术TCP Socket编程IP地址及端口问题IP层会分片为什么TCP层还需要MSS呢HTTP3放弃TCPNAPTNetwork Address Port Transfer , 网络地址端口转换 工作原理。常用网络命令常用协议 墙裂推荐网络学习参考 OSIOpen Systems Interconnection模型 应用层 应用层最接近终端用户。大多数应用程序都位于这一层。我们从后端服务器请求数据无需了解数据传输的具体细节。这一层的协议包括 HTTP、SMTP、FTP、DNS 等。表现层 这一层处理数据编码、加密和压缩为应用层准备数据。例如HTTPS 利用 TLSTransport Layer Security实现客户端与服务器之间的安全通信。会话层 该层用于打开和关闭两个设备之间的通信。如果数据量较大会话层就会设置检查点避免从头开始重新发送。传输层 该层处理两个设备之间的端到端的通信。它在发送方将数据分解成段然后在接收方重新组装。这一层有流量控制以防止拥塞。这一层的主要协议是 TCP 和 UDP。网络层 这一层实现不同网络之间的数据传输。它进一步将网段或数据报分解成更小的数据包并使用 IP 地址找到通往最终目的地的最佳路由。数据链路层 这一层允许在同一网络的设备之间传输数据。数据包被分解成帧这些帧被限制在局域网内。物理层 这一层通过电缆和交换机发送比特流因此与设备之间的物理连接密切相关。 与OSI模型相比TCP/IP 模型只有4层。在讨论网络协议的层次时必须明确上下文。 OSI 封装 每一层都使用报头来处理指令而不需要解封上一层的数据。 步骤 1 当设备 A 使用 HTTP 通过网络向设备 B 发送数据时最初会在应用层添加一个 HTTP 报头。步骤 2 在数据中添加 TCP 或 UDP 报头。它在传输层被封装成 TCP 段。报头包含源端口、目的端口和序列号。步骤 3 然后在网络层用 IP 报头对这些段落进行封装。IP 报头包含源 IP 地址和目的 IP 地址。步骤 4 在数据链路层为 IP 数据报添加 MAC 报头其中包含源 MAC 地址和目的 MAC 地址。步骤 5 封装帧被发送到物理层并作为比特流在网络上发送。步骤 6-10 设备 B 从网络接收到比特流后会启动去封装过程这与封装过程相反。报头逐层去除直到设备 B 可以访问原始数据。 TCP/IP协议栈 TCP/IP协议栈是一组用于网络通信的协议它包括物理层、数据链路层、网络层、传输层和应用层。每个层次的协议都提供了不同的功能例如网络层协议IP负责将数据包从一个主机传输到另一个主机而传输层协议TCP提供可靠的数据传输。 IP数据报的报头 IP数据报的报头包含以下字段 版本Version指定IP协议的版本通常为IPv4或IPv6。首部长度Header Length指定IP报头的长度以32位字4字节为单位。服务类型Type of Service用于指定数据报的服务质量要求如优先级、延迟、吞吐量等。总长度Total Length指定整个IP数据报的长度包括报头和数据部分。标识Identification用于唯一标识一个IP数据报通常由发送方设置接收方用于重组分片。标志Flags包含3个标志位分别是DFDon’t Fragment不分片、MFMore Fragments更多分片、和保留位。分片偏移Fragment Offset用于指示当前分片相对于原始数据报的偏移量以8字节为单位。生存时间Time to Live指定数据报在网络中可以经过的最大路由器跳数每经过一个路由器该值减1为0时数据报被丢弃。协议Protocol指定IP数据报中承载的上层协议如TCP、UDP、ICMP等。头部校验和Header Checksum用于检验IP报头的完整性接收方使用该字段来验证报头是否正确。源IP地址Source IP Address指定发送方的IP地址。目标IP地址Destination IP Address指定接收方的IP地址。 TCP头格式 序列号在建立连接时由计算机生成的随机数作为其初始值通过 SYN 包传给接收端主机每发送一次数据就「累加」一次该「数据字节数」的大小。用来解决网络包乱序问题。确认应答号指下一次「期望」收到的数据的序列号发送端收到这个确认应答以后可以认为在这个序号以前的数据都已经被正常接收。用来解决丢包的问题。控制位 ACK该位为 1 时「确认应答」的字段变为有效TCP 规定除了最初建立连接时的 SYN 包之外该位必须设置为 1 。RST该位为 1 时表示 TCP 连接中出现异常必须强制断开连接。SYN该位为 1 时表示希望建立连接并在其「序列号」的字段进行序列号初始值的设定。FIN该位为 1 时表示今后不会再有数据发送希望断开连接。当通信结束希望断开连接时通信双方的主机之间就可以相互交换 FIN 位为 1 的 TCP 段。
IP 层是“不可靠”的它不保证网络包的交付、不保证网络包的按序交付、也不保证网络包中的数据的完整性。源地址和目的地址的字段32 位是在 IP 头部中。 TCP 是一个工作在传输层的可靠数据传输的服务它能确保接收端接收的网络包是无损坏、无间隔、非冗余和按序的。总之TCP 是面向连接的、可靠的、基于字节流的传输层通信协议。 面向连接一定是「一对一」才能连接不能像 UDP 协议可以一个主机同时向多个主机发送消息也就是一对多是无法做到的可靠的无论的网络链路中出现了怎样的链路变化TCP 都可以保证一个报文一定能够到达接收端字节流用户消息通过 TCP 协议传输时消息可能会被操作系统「分组」成多个的 TCP 报文如果接收方的程序如果不知道「消息的边界」是无法读出一个有效的用户消息的。并且 TCP 报文是「有序的」当「前一个」TCP 报文没有收到的时候即使它先收到了后面的 TCP 报文那么也不能扔给应用层去处理同时对「重复」的 TCP 报文会自动丢弃。 建立一个 TCP 连接是需要客户端与服务端达成上述三个信息的共识。 Socket由 IP 地址和端口号组成序列号用来解决乱序问题等窗口大小用来做流量控制 TCP 四元组可以唯一的确定一个连接 源地址源端口目的地址目的端口 UDP头格式 UDP 不提供复杂的控制机制利用 IP 提供面向「无连接」的通信服务。UDP 协议头部只有 8 个字节64 位UDP 的头部格式如下
目标和源端口主要是告诉UDP协议应该把报文发给哪个进程。包长度该字段保存了UDP首部的长度跟数据的长度之和。校验和校验和是为了提供可靠的UDP首部和数据而设计防止收到在网络传输中受损的UDP包。 TCP (3-way shake)三次握手建立连接 一开始客户端和服务端都处于CLOSE状态。先是服务端主动监听某个端口处于LISTEN状态. 客户端会随机初始化序号client_isn将此序号置于 TCP 首部的 “序列号” 字段中同时把 SYN 标志位置为 1表示 SYN 报文。接着把第一个 SYN 报文发送给服务端表示向服务端发起连接该报文不包含应用层数据之后客户端处于 SYN-SENT 状态。 服务端收到客户端的 SYN 报文后首先服务端也随机初始化自己的序号server_isn将此序号填入 TCP 首部的 “序列号” 字段中其次把 TCP 首部的 “确认应答号” 字段填入 client_isn 1, 接着把 SYN 和 ACK 标志位置为 1。最后把该报文发给客户端该报文也不包含应用层数据之后服务端处于 SYN-RCVD 状态。 客户端收到服务端报文后还要向服务端回应最后一个应答报文首先该应答报文 TCP 首部 ACK 标志位置为 1 其次 “确认应答号” 字段填入 server_isn 1 最后把报文发送给服务端这次报文可以携带客户到服务端的数据之后客户端处于 ESTABLISHED 状态。服务端收到客户端的应答报文后也进入 ESTABLISHED 状态。 为什么三次握手才可以初始化 Socket、序列号和窗口大小并建立 TCP 连接。 首先是为了防止旧的重复连接初始化造成混乱(避免历史连接)。 考虑一个场景客户端先发送了 SYNseq 90报文然后客户端宕机了而且这个 SYN 报文还被网络阻塞了服务端并没有收到接着客户端重启后又重新向服务端建立连接发送了 SYNseq 100报文注意不是重传 SYN重传的 SYN 的序列号是一样的。 客户端连续发送多次 SYN都是同一个四元组建立连接的报文在网络拥堵情况下 一个 “旧 SYN 报文seq 90”比 “最新的 SYNseq 100” 报文早到达了服务端那么此时服务端就会回一个 SYN ACK 报文给客户端此报文中的确认号是 91901。客户端收到后发现自己期望收到的确认号应该是 100 1而不是 90 1于是就会回 RST 报文。服务端收到 RST 报文后就会释放连接。后面 “最新的 SYN ” 抵达了服务端后客户端与服务端就可以正常的完成三次握手了。 上述中的 “旧 SYN 报文” 称为历史连接TCP 使用三次握手建立连接的最主要原因就是防止 “历史连接 初始化了连接。 如服务端收到客户端报文的顺序是“旧 SYN 报文” -“新 SYN 报文”此时会发生什么 当服务端第一次收到 SYN 报文也就是收到 “旧 SYN 报文” 时就会回复 SYN ACK 报文给客户端此报文中的确认号是 91901。然后这时再收到 “新 SYN 报文” 时就会回 Challenge Ack报文给客户端这个 ack 报文并不是确认收到 “新 SYN 报文” 的而是上一次的 ack 确认号也就是91901。所以客户端收到此 ACK 报文时发现自己期望收到的确认号应该是 101而不是 91于是就会回 RST 报文。 在两次握手的情况下服务端没有中间状态给客户端来阻止历史连接导致服务端可能建立一个历史连接造成资源浪费。 其次为了同步双方初始序列号 TCP协议的通信双方 都必须维护一个 “序列号” 序列号是可靠传输的一个关键因素作用 接收方可以去除重复的数据接收方可以根据数据包的序列号按序接收可以标识发送出去的数据包中 哪些是已经被对方收到的通过 ACK 报文中的序列号知道 可见序列号在TCP连接中占据着非常重要的作用所以当客户端发送携带 “初始序列号” 的 SYN 报文的时候需要服务端回一个 ACK 应答报文表示客户端的 SYN 报文已被服务端成功接收那当服务端发送 “初始序列号” 给客户端的时候依然也要得到客户端的应答回应。这样一来一回才能确保双方的初始序列号能被可靠的同步。 避免资源浪费 如果只有 “两次握手”当客户端发生的 SYN 报文在网络中阻塞客户端没有接收到 ACK 报文就会重新发送 SYN 由于没有第三次握手服务端不清楚客户端是否收到了自己回复的 ACK 报文所以服务端每收到一个 SYN 就只能先主动建立一个连接。 如果客户端发送的 SYN 报文在网络中阻塞了重复发送多次 SYN 报文那么服务端在收到请求后就会建立多个冗余的无效链接造成不必要的资源浪费。
每次建立TCP连接时初始化的序列号都要求不一样 主要原因有两个方面 主要是为了防止历史报文被下一个相同四元组的连接接收。其次为了安全性防止黑客伪造的相同序列号的TCP报文被对方接收。 接收历史相同四元组的过程如下 客户端和服务端建立一个TCP连接在客户端发送数据包被网络阻塞了然后超时重传了这个数据包而此时服务端设备断电重启了之前与客户端建立的连接就消失了于是在收到客户端的数据包的时候就会发送RST报文。紧接着客户端又与服务端建立了与上一个连接相同四元组的连接在新连接建立完成后上一个连接中被网络阻塞的数据包正好抵达了服务端刚好该数据包的序列号正好是在服务端的接收窗口内所以该数据包会被服务端正常接收就会造成数据错乱。 初始序列号ISN是如何随机产生的 起始ISN是基于时钟的每4微秒1转一圈要4.55个小时。 大量SYN包发送给服务端服务端会怎样 可能会导致TCP半连接队列满如TCP半连接队列满了后续再在收到SYN报文就会丢弃导致客户端无法和服务端建立连接。避免SYN攻击方式可以有以下四种方法 调大netdev_max_backlog增大TCP半连接队列开启tcp_syncookies减少SYNACK重传次数 TCP四次挥手断开 客户端主动调用关闭连接的函数于是就会发送 FIN 报文这个 FIN 报文代表客户端不会再发送数据了进入 FIN_WAIT_1 状态服务端收到了 FIN 报文然后马上回复一个 ACK 确认报文此时服务端进入 CLOSE_WAIT 状态。在收到 FIN 报文的时候TCP 协议栈会为 FIN 包插入一个文件结束符 EOF 到接收缓冲区中服务端应用程序可以通过 read 调用来感知这个 FIN 包这个 EOF 会被放在已排队等候的其他已接收的数据之后所以必须要得继续 read 接收缓冲区已接收的数据接着当服务端在 read 数据的时候最后自然就会读到 EOF接着 read() 就会返回 0这时服务端应用程序如果有数据要发送的话就发完数据后才调用关闭连接的函数如果服务端应用程序没有数据要发送的话可以直接调用关闭连接的函数这时服务端就会发一个 FIN 包这个 FIN 报文代表服务端不会再发送数据了之后处于 LAST_ACK 状态客户端接收到服务端的 FIN 包并发送 ACK 确认包给服务端此时客户端将进入 TIME_WAIT 状态服务端收到 ACK 确认包后就进入了最后的 CLOSE 状态客户端经过 2MSL 时间之后也进入 CLOSE 状态 每个方向都需要一个 FIN 和一个 ACK因此通常被称为四次挥手。 第二次挥手丢失 客户端会触发超时重传 FIN 报文达到最大的重传次数再等待一段时间客户端就会断开连接。第三次挥手丢失 服务端重传第三次挥手报文达到最大值再等待一段时间服务端就会断开连接。客户端如tcp_fin_timeout 时间内还是没能收到服务端的第三次挥手FIN 报文那么客户端就会断开连接。第四次挥手丢失 当客户端收到服务端的第三次挥手的 FIN 报文后就会回 ACK 报文也就是第四次挥手此时客户端连接进入 TIME_WAIT 状态。持续 2MSL 后才会进入关闭状态。 为什么 TIME_WAIT 等待的时间是 2MSL(MSL 是 Maximum Segment Lifetime报文最大生存时间) 防止历史连接中的数据被后面相同四元组的连接错误的接收 为了防止历史连接中的数据被后面相同四元组的连接错误的接收因此 TCP 设计了 TIME_WAIT 状态状态会持续 2MSL 时长这个时间足以让两个方向上的数据包都被丢弃使得原来连接的数据包在网络中都自然消失再出现的数据包一定都是新建立连接所产生的。 保证 “被动关闭连接” 的一方能被正确的关闭 TIME-WAIT 作用是等待足够的时间以确保最后的 ACK 能让被动关闭方接收从而帮助其正常关闭。 如果客户端主动关闭方最后一次 ACK 报文第四次挥手在网络中丢失了那么按照 TCP 可靠性原则服务端被动关闭方会重发 FIN 报文。 假设客户端没有 TIME_WAIT 状态而是在发完最后一次回 ACK 报文就直接进入 CLOSE 状态如果该 ACK 报文丢失了服务端则重传的 FIN 报文而这时客户端已经进入到关闭状态了在收到服务端重传的 FIN 报文后就会回 RST 报文。服务端收到这个 RST 并将其解释为一个错误Connection reset by peer这对于一个可靠的协议来说不是一个优雅的终止方式。
当存在大量close_wait的连接时怎么处理 CLOSE_WAIT 状态是被动关闭方才会有的状态而且如果被动关闭方没有调用 close 函数关闭连接那么就无法发出 FIN 报文从而无法使得 CLOSE_WAIT 状态的连接转变为 LAST_ACK 状态。 所以当服务端出现大量 CLOSE_WAIT 状态的连接的时候说明服务端的程序没有调用 close 函数关闭连接。
大量TIME_WAIT什么原因 TIME_WAIT 状态是主动关闭连接方才会出现的状态所以如果服务器出现大量的 TIME_WAIT 状态的 TCP 连接就是说明服务器主动断开了很多 TCP 连接。 TCP连接中客户端和服务器之间操作 握手阶段客户端向服务器发送SYN包同步包请求建立连接。服务器收到SYN包后向客户端发送SYNACK包同步确认包表示可以建立连接。客户端收到SYNACK包后再向服务器发送ACK包确认包表示连接建立成功。数据传输阶段连接建立成功后客户端和服务器之间可以进行数据的传输。客户端向服务器发送数据包服务器接收数据包并进行处理然后向客户端发送响应包。客户端收到响应包后可以再次向服务器发送数据包以此类推。断开连接阶段当客户端或服务器不再需要连接时可以发送FIN包结束包来请求断开连接。对方收到FIN包后也发送FIN包进行响应表示同意断开连接。当两端都收到对方的FIN包后连接才真正关闭。 TCP如何实现可靠传输 序列号与确认应答TCP将每个发送的数据包进行编号序列号接收方通过发送确认应答ACK来告知发送方已成功接收到数据。如果发送方在一定时间内未收到确认应答会进行超时重传。数据校验TCP使用校验和来验证数据在传输过程中是否发生了损坏。接收方会计算校验和并与发送方发送的校验和进行比较如果不一致则说明数据包发生了损坏需要重新发送。滑动窗口控制TCP使用滑动窗口机制来控制发送方和接收方之间的数据流量。发送方根据接收方的处理能力和网络状况来调整发送的数据量接收方则通过窗口大小来告知发送方可以接收的数据量。重传机制如果发送方未收到确认应答或接收方检测到数据错误TCP会进行重传。发送方会根据超时时间或接收方的冗余确认来触发重传以确保数据的可靠传输。拥塞控制TCP使用拥塞控制算法来避免网络拥塞。通过动态调整发送速率和窗口大小TCP可以根据网络的拥塞程度来进行适当的调整以提高网络的利用率和稳定性。 TCP 流量控制、拥塞控制 发送方发数据给接收方要考虑接收方处理能力如果接收方对方处理不过来那么就会导致触发重发机制从而导致网络流量的无端的浪费。为了解决这种现象发生 TCP 提供一种机制可以让发送方根据接收方的实际接收能力控制发送的数据量这就是所谓的流量控制。 在网络出现拥堵时如果继续发送大量数据包可能会导致数据包时延、丢失等这时 TCP 就会重传数据但重传就会导致网络的负担更重于是会导致更大的延迟以及更多的丢包这个情况就会进入恶性循环。当网络发送拥塞时TCP会自我牺牲降低发送的数据量。于是就有了拥塞控制目的就是避免发送方的数据填满整个网络。 TCP传输协议中流量控制是使用滑动窗口Sliding Window来实现的。滑动窗口是一种基于数据流的、动态调整的、可变大小的窗口它通过协商双方的接收窗口和发送窗口大小控制数据的传输速率。 在TCP协议中每个数据包都有一个序号接收方通过序号来确认是否收到了正确的数据包。发送方将数据分成若干个数据段每个数据段的大小不超过发送窗口的大小然后将这些数据段发送给接收方。接收方会确认已经收到的数据同时告诉发送方自己的接收窗口大小。发送方根据接收方的窗口大小动态调整自己的发送窗口大小从而控制数据的传输速率。 滑动窗口的大小是可以动态调整的它可以根据网络状况和双方的能力来自适应地调整从而实现流量控制的功能。如果接收方的接收窗口变小发送方会相应地减小自己的发送窗口以避免过多的数据堆积在网络中导致拥塞。如果接收方 的接收窗口变大发送方会相应地增加自己的发送窗口以提高数据传输速率。 TCP和UDP的区别 连接。TCP 是面向连接的传输层协议传输数据前先要建立连接。UDP是不需要连接即刻传输数据。TCP建立和释放连接需要进行三次握手和四次挥手。UDP无需进行三次握手和四次挥手。说明UDP比TCP实时性更强。首部开销。TCP 首部长度较长会有一定的开销首部在没有使用选项字段时是 20 个字节如果使用了选项字段则会变长的。UDP 首部只有 8 个字节并且是固定不变的开销较小。服务对象。TCP 是一对一的两点服务即一条连接只有两个端点。UDP 支持一对一、一对多、多对多的交互通信可靠性。TCP 是可靠交付数据的数据可以无差错、不丢失、不重复、按序到达。UDP 是尽最大努力交付不保证可靠交付数据。但是我们可以基于 UDP 传输协议实现一个可靠的传输协议比如 QUIC 协议。拥塞控制、流量控制。TCP 有拥塞控制和流量控制机制保证数据传输的安全性。UDP 则没有即使网络非常拥堵了也不会影响 UDP 的发送速率。传输方式。TCP 是流式传输没有边界但保证顺序和可靠。UDP 是一个包一个包的发送是有边界的但可能会丢包和乱序。分片不同。TCP 的数据大小如果大于 MSS 大小则会在传输层进行分片目标主机收到后也同样在传输层组装 TCP 数据包如果中途丢失了一个分片只需要传输丢失的这个分片。UDP 的数据大小如果大于 MTU 大小则会在 IP 层进行分片目标主机收到后在 IP 层组装完数据接着再传给传输层。应用场景不同。 TCP是面向连接能保证数据的可靠性交付因此经常用于FTP文件传输HTTP/HTTPS网页、电子邮件、远程登录连接 UDP面向无连接随时发送数据再加上UDP本身的处理既简单又高效因此经常用于包总量较少的通信如DNS、SNMP等、视频、音频等多媒体通信、广播通信。 为什么UDP头部没有 “首部长度” 字段而TCP头部有 “首部长度” 字段 TCP有可变长的 “选项” 字段而UDP头部长度则是不会变化的无需多一个字段去记录UDP的首部长度。 为什么UDP头部有 “包长度” 字段而TCP头部则没有 “包长度” 字段 TCP的负载数据长度 可以根据IP总长度、IP首部长度IP首部格式是已知的、TCP首部长度求得TCP数据的长度。 TCP粘包问题 TCP的粘包问题是指当发送方将多个数据包连续发送到接收方时接收方可能将它们看作单个大的数据包。这种问题可能会导致数据丢失或数据不完整。为了避免TCP的粘包问题可以使用一些技术如消息边界标记、消息长度标记和消息头标记。 固定长度的消息 这种是最简单方法即每个用户消息都是固定长度的比如规定一个消息的长度是 64 个字节当接收方接满 64 个字节就认为这个内容是一个完整且有效的消息。 但是这种方式灵活性不高实际中很少用。特殊字符作为边界 我们可以在两个用户消息之间插入一个特殊的字符串这样接收方在接收数据时读到了这个特殊字符就把认为已经读完一个完整的消息。自定义消息结构 我们可以自定义一个消息结构由包头和数据组成其中包头包是固定大小的而且包头里有一个字段来说明紧随其后的数据有多大。 UDP的粘包问题是指当发送方将多个数据包连续发送到接收方时接收方可能将它们看作单个大的数据包。这种问题可能会导致数据丢失或数据不完整。UDP协议本身并没有提供解决粘包问题的机制因此应用程序需要自己解决这个问题。解决粘包问题的方法包括使用消息边界标记、消息长度标记和消息头标记等。 TCP重置技术 “伪造RST报文来关闭TCP连接” 的方式叫做TCP重置攻击伪造RST报文时要保证伪造的RST报文的序列号能被对方接受。 tcpkill工具是在双方进行TCP通信时拿到对方下一次期望收到的序列号然后将序列号填充到伪造的RST报文并将其发送给对方达到关闭TCP连接的效果。 tcpkill工具属于被动获取就是在双方进行TCP通信的时候才能获取到正确的序列号很显然这种方式无法关闭非活跃的TCP连接只能用于关闭活跃的TCP连接。因为如果这条TCP连接一直没有任何数据传输则就永远获取不到正确的序列号。 killcx工具是主动发送一个SYN报文对方收到后会回复一个携带了正确序列号和确认号的ACK报文这个ACK被称之为ChallengeACK这时就可以拿到对方下一次期望收到的序列号然后将序列号填充到伪造的RST报文并将其发送给对方达到关闭TCP连接的效果。 killcx工具则是属于主动获取它是主动发送一个SYN报文通过对方回复的ChallengeACK来获取正确的序列号所以这种方式无论TCP连接是否活跃都可以关闭。
TCP Socket编程 服务端和客户端初始化socket得到文件描述符服务端调用bind将socket绑定在指定的IP地址和端口;服务端调用listen进行监听服务端调用accept等待客户端连接客户端调用connect向服务端的地址和端口发起连接请求服务端accept返回用于传输的socket的文件描述符客户端调用write写入数据服务端调用read读取数据客户端断开连接时会调用close那么服务端read读取数据的时候就会读取到了EOF待处理完数据后服务端调用close表示连接关闭。 连接的主要实现步骤 服务器端socker()建立套接字绑定bind并监听listen用accept 等待客户端连接。客户端socker()建立套接字连接connect服务器连接上后使用send()和recv 在套接字上写读数据直至数据交换完毕close socket()关闭套接字。服务器端accept发现有客户端连接建立一个新的套接字自身重新开始等待连 接。该新产生的套接字使用send()和recv写读数据直至数据交换完毕closesock et()关闭套接字。 IP地址及端口问题 客户端连接一个不存在的IP地址会怎样 目标IP地址和客户端的IP地址是同一个局域网网络号相同的情况。 客户端无法发出SYN报文主要卡在数据链路层。因为目标地址不存在IP地址客户端的内核在发arp请求的时候广播询问这个目标IP地址是谁的由于网络中不存在该目标IP地址所以没有设备应答客户端的arp请求。由于客户端无法拿到目标设备的MAC这样就没办法组装MAC头的信息所以SYN报文无法发送出去。 目标IP地址和客户端的IP地址不在同一个局域网网络号不同情况。 客户端会先将SYN报文发给路由器然后路由器会继续转发。由于目标IP地址是不存在的该SYN报文会在网络中消亡因此客户端是不会收到对SYN报文的确认报文的接着客户端会触发超时重传重传SYN报文直到重传的次数达到最大次数后客户端的连接就会被释放。 客户端连接一个存在的IP地址但是端口不存在会怎样 客户端连接的目标IP地址是存在的那么SYN报文就能正确的抵达到目标设备。目标设备收到SYN报文后发现端口号并没有被进程监听这时候目标设备的内核就会回RST报文。 一个IP的服务端监听了一个端口它的TCP的最大连接数是多少 服务端通常固定在某个本地端口上监听等待客户端的连接请求。因此客户端IP和端口是可变的其理论值计算公式如下:客户端IP数 * 客户端端口数。 服务端最大并发TCP连接数远不能达到理论上限会受以下因素影响 文件描述符限制每个TCP连接都是一个文件如果文件描述符被占满了会发生Too many open files。Linux对可打开的文件描述符的数量分别作了三个方面的限制 系统级当前系统可打开的最大数量通过 cat /proc/sys/fs/file-max 查看 用户级指定用户可打开的最大数量通过 cat /etc/security/limits.conf 查看 进程级单个进程可打开的最大数量通过 cat /proc/sys/fs/nr_open 查看内存限制每个TCP连接都要占用一定内存操作系统的内存是有限的如果内存资源被占满后会发生OOM。 TCP和UDP可以使用同一个端口吗 在数据链路层中通过MAC地址来寻找局域网中的主机。 在网际层中通过IP地址来寻找网络中互连的主机或路由器。 在传输层中需要通过端口进行寻址来识别同一计算机中同时通信的不同应用程序。 所以传输层的「端口号」的作用是为了区分同一个主机上不同应用程序的数据包。 传输层有两个传输协议分别是TCP和UDP在内核中是两个完全独立的软件模块。 当主机收到数据包后可以在IP包头的 “协议号” 字段知道该数据包是TCP/UDP所以可以根据这个信息确定送给哪个模块TCP/UDP处理送给TCP/UDP模块的报文根据 “端口号” 确定送给哪个应用程序处理。 因此TCP/UDP各自的端口号也相互独立如TCP有一个80号端口UDP也可以有一个80号端口二者并不冲突。 客户端的端口可以重复使用吗 只要客户端连接的不是相同的服务器内核是允许端口重复使用的。TCP连接由四元组源IP地址源端口目的IP地址目的端口唯一确认的四元组其中任何一个元素改变就表示不同的TCP连接。 假如客户使用端口1与服务器A建立了连接客户端也可以使用端口1与服务器B建立连接即使客户端的端口号相同但因四元组信息发生变化并不会导致连接冲突。 多个TCP服务进程可以绑定同一个端口吗 若多个TCP服务进程同时绑定相同的IP地址和端口那么执行bind()时候就会报错“Addressalreadyinuse”若TCP服务进程只是绑定相同的端口但绑定的IP地址不同那么则不会报错。
IP层会分片为什么TCP层还需要MSS呢 MTU一个网络包的最大长度以太网中一般为1500字节 MSS除去IP和TCP头部之后一个网络包所能容纳的TCP数据的最大长度 如果在TCP的整个报文头部数据交给IP层进行分片而IP层本身没有超时重传机制它由传输层的TCP来负责超时和重传。 当某一个IP分片丢失后接收方的IP层就无法组装成一个完整的TCP报文头部数据也就无法将数据报文送到TCP层所以接收方不会响应ACK给发送方因为发送方迟迟收不到ACK确认报文所以会触发超时重传就会重发 “整个TCP报文头部数据” 。因此由IP层进行分片传输是非常没有效率的。 所以为了达到最佳的传输效能TCP协议在建立连接的时候通常要协商双方的MSS值当TCP层发现数据超过MSS时则就先会进行分片当然由它形成的IP包的长度也就不会大于MTU自然也就不用IP分片了。 经过TCP层分片后如果一个TCP分片丢失后进行重发时也是以MSS为单位而不用重传所有的分片大大增加了重传的效率。 HTTP3放弃TCP TCP存在队头阻塞问题———TCP发送出去的数据都是需要按序确认的只有在数据都被按顺序确认完后发送窗口才会往前滑动。如果某个数据报文丢失或者其对应的ACK报文在网络中丢失会导致发送方无法移动发送窗口这时就无法再发送新的数据。如客户端发送了第59字节的数据但是第5字节的ACK确认报文在网络中丢失了那么即使客户端收到第69字节的ACK确认报文发送窗口也不会往前移动。此时的第5字节相当于 “队头” 因为没有收到 “队头” 的ACK确认报文导致发送窗口无法往前移动此时发送方就无法继续发送后面的数据相当于按下了发送行为的暂停键这就是发送窗口的队头阻塞问题。接收窗口的队头阻塞————接收窗口收到的数据不是有序的比如收到第3340字节的数据由于第32字节数据没有收到接收窗口无法向前滑动那么即使先收到第3340字节的数据这些数据也无法被应用层读取的。 两个问题的原因都是因为TCP必须按序处理数据也就是TCP层为了保证数据的有序性只有在处理完有序的数据后滑动窗口才能往前滑动否则就停留。 NAPTNetwork Address Port Transfer , 网络地址端口转换 工作原理。 发送流程 发送端IP地址填的就是192.168.30.5接收端IP地址就是30.30.30.30。将数据包发到NAT路由器中。 此时NAT路由器会将IP数据包里的源IP地址和端口号修改一下从192.168.30.5:5000改写成20.20.20.20:6000。并且还会在NAT路由器内部留下一条192.168.30.5:5000-20.20.20.20:6000的映射记录。之后数据包经过公网里各个路由器的转发发到了接收端30.30.30.30:3000到这里发送流程结束。 接收流程 接收端响应时就会在数据包里填入发送端地址是30.30.30.30:3000将接收端是20.20.20.20:6000发往NAT路由器。NAT路由器发现下自己之前留下过这么一条192.168.30.5:5000-20.20.20.20:6000的记录就会将这个数据包的目的IP地址和端口修改一下变回原来的192.168.30.5:5000。之后将其转发给你的电脑上。
ping基于ICMP协议ICMP协议报文里并不带端口信息 事实上针对ICMP协议NAT路由器做了特殊处理。ping报文头里有个Identifier的信息它其实指的是放出ping命令的进程id。对NAT路由器来说这个Identifier的作用就跟端口一样所以可以ping通公网机器并收到回包。 内网穿透 使用了NAT上网的话前提得内网机器主动请求公网IP这样NAT才能将内网的IP端口转成外网IP端口。 反过来公网的机器想主动请求内网机器就会被拦在NAT路由器上此时由于NAT路由器并没有任何相关的IP端口的映射记录因此也就不会转发数据给内网里的任何一台机器。 我们就在公网上加一台服务器x并暴露一个访问域名再让内网的服务主动连接服务器x这样NAT路由器上就有对应的映射关系。接着所有人都去访问服务器x服务器x将数据转发给内网机器再原路返回响应这样数据就都通了。这就是所谓的内网穿透。 上面提到的服务器x也不需要自己去搭已经有很多现成的方案比如花某壳。
常用网络命令 route nc 工具 netstat 命令 IP分配 手动在电脑里配IP地址还需要配上子网掩码和路由器的地址。DHCPDynamic Host Configuration Protocol动态主机配置协议。在联网之后可以自动获取到本机需要的IP地址子网掩码还有路由器地址。

在命令行里执行下面的命令可以强行让电脑的en0网卡重新走一遍DHCP流程。

sudo ipconfig set en0 DHCP# 在 Linux下TCP 的连接状态可以通过 netstat -napt 命令查看。 netstat -tunlp # 用于显示所有TCP和UDP端口的监听状态。 lsof -i :端口号 # 用于显示指定端口的相关信息。

查看哪个端口被哪个进程占用,可以通过 lsof 或者 netstate 命令查看比如查看 80 端口。

lsof -i :80 netstat -napt | grep 80# 查看close_wait状态的连接 netstat -napt | grep close_wait# sort -k3 -nr用于按第三列请求耗时进行倒序排序。

-k3表示按第三列排序-n表示按数字排序-r表示倒序排序。

然后使用head -n 10来获取排序后的前10行即耗时最高的10条记录。

sort -k3 -nr 日志文件 | head -n 10# telnet命令用于建立与远程主机的Telnet连接并可以使用telnet命令测试特定端口的可访问性。 telnet IP地址 端口号 # 用于测试指定IP地址上的指定端口是否可访问。

如果能够建立连接则表示端口通畅如果连接失败或超时则表示端口不可访问。# nc命令也称为netcat是一个网络工具可以用于创建各种类型的网络连接包括测试端口的可访问性。

nc -zv IP地址 端口号 # 用于测试指定IP地址上的指定端口是否可访问。 #如果能够成功连接则表示端口通畅如果连接失败或拒绝则表示端口不可访问。 常用协议 ARP (Address Resolution Protocol) - Internet物理地址和IP地址转换 ICMP - Internet控制报文协议处于网络层IP层 ARQ - 自动重传请求Automatic Repeat-reQuest是 OSI 模型中数据链路层和传输层的错误纠正协议之一。它通过使用确认和超时这两个机制在不可靠服务的基础上实现可靠的信息传输。 ICMP - Internet Control Message Protocol - Internet控制消息协议。 墙裂推荐网络学习参考 图解网络介绍