TCP全称为TransmissionControlProtocol（传输控制协议），是一种面向连接的、可靠的、基于字节流的传输层通信协议，其中可靠性是相对于其他传输协议的优势点。TCP为了确保数据传输的可靠性主要做了以下几点：发送确认机制丢包重传机制滑动窗口拥塞控制TCP的传输基于字节流，记录起始序列号、是否发送、是否接收。本文从实战出发，使用Wireshark抓包工具来分析具体的请求。确认和重传TCP报文头中有两个字段：Sequencenumber序列号：表示要发送数据的起始号Acknowledgmentnumber确认号：表示消息已经接收，返回下次要发送的起始号发送确认TCP每次发送数据，
🐱作者：一只大喵咪1201🐱专栏：《网络》🔥格言：你只管努力，剩下的交给时间！现在是传输层，在应用层中的报文(报头+有效载荷)就不能被叫做报文了，而是叫做数据段(报头+有效载荷)，传输层的有效载荷就是应用层的完整报文。目录🏺再谈端口号🥝端口号划分🏺UDP🥝协议格式🥝解包和分用🥝特点🏺TCP🥝协议格式🥝解包和分用🥝可靠性确认应答(ACK)机制超时重传机制连接管理机制理解TIME_WAIT状态理解CLOSE_WAIT状态🏺总结🏺再谈端口号端口号(port)：标识了一个主机上进行通信的不同的应用程序。如上图所示，FTP，SSH，SMTP，HTTP，FTP等类型的服务器，其实就是在一台机器上运行着的不
重传次数 tcp通过设置R1值来确定：愿意尝试重传多少次之后，向IP层传递重新评估当前的IP路径。 tcp通过设置R2值来确定：愿意尝试重传多少次之后，放弃当前连接。 Linux通过分别设置net.ipv4.tcp_retries1和net.ipv4.tcp_retries2来设置R1和R2值。 对于建立连接的SYN与SYN_ACK重传次数，Linux通过分别设置net.ipv4.tcp_syn_retries和net.ipv4.tcp_synack_retries来设置。带TSOPT（TimeStamp）选项的RTO计算 rto（Retr
我们遇到了一个问题，一段时间后，特定的套接字连接被阻塞，客户端的tcp内核不断重传[ACK]数据包。拓扑流程如下:ClientA←→SwitchA←RouterA:NAT←..Internet..→RouterB:NAT→SwitchB←→ServerB以下是WireShark抓取的数据包:一)服务器1.8013>6757[PSH,ACK]Seq=56Ack=132Win=5840Len=552.6757>8013[ACK]Seq=132Ack=111Win=65425Len=0B)客户//lines3and4areexactlythesameasline1and23.8013>130
我们遇到了一个问题，一段时间后，特定的套接字连接被阻塞，客户端的tcp内核不断重传[ACK]数据包。拓扑流程如下:ClientA←→SwitchA←RouterA:NAT←..Internet..→RouterB:NAT→SwitchB←→ServerB以下是WireShark抓取的数据包:一)服务器1.8013>6757[PSH,ACK]Seq=56Ack=132Win=5840Len=552.6757>8013[ACK]Seq=132Ack=111Win=65425Len=0B)客户//lines3and4areexactlythesameasline1and23.8013>130
TCP的拥塞控制一、前言：什么是拥塞？什么是拥塞控制？拥塞：随着网络中的主机增加其发送速率并使网络变得十分拥挤，此时会经常发生丢包现象，导致网络的传输效率急剧降低。分组的超时重传通常被作为网络拥塞的标志。如果不对网络拥塞进行控制，整个网络的吞吐量将随着输入负荷的增大而下降，降低网络的传输效率，如下图：二、TCP的4种拥塞控制算法(慢开始、拥塞避免、快重传、快恢复)为了便于讨论做一下假设数据是单方向传送的，另一个方向只传输确认接收方的总是有足够大的缓冲区，因此发送方的发送窗口仅由网络的拥塞程度决定，事实上发送窗口的大小由拥塞窗口和接收方的接收窗口大小共同控制，也即发送窗口=min[接收窗口,拥塞
目录一、滑动窗口的来由二、滑动窗口1、滑动窗口模型2、滑动窗口可能出现的状况(1)客户端发送的报文丢了（快重传机制）(2)服务端发送的ACK丢了（先收到了排序靠后的ACK）三、滑动窗口大小为0时，何时才能继续发送数据？1、策略一：发送方定期发送不携带数据的报文2、策略二：接收方缓冲区一旦更新立马通知发送方四、总结一、滑动窗口的来由TCP由于存在确认应答机制，在一方发出一条消息以后，另一方要发送ACK表明自己收到消息。如果按照下面这种形式，每次收到ACK才发出下一条消息，这种一发一收的效率太低。但是如果客户端不急着接收ACK，可以利用等待ACK的空挡直接发送下一批数据，这样就可以做到短时间内发送
小白:大牛你好，我是一名即将毕业的大学生，最近正在准备找工作，但是我对TCP中的快速重传和慢启动不是很了解，能否请您帮我解释一下呢？大牛:当然可以，TCP中的快速重传和慢启动是TCP拥塞控制算法中非常重要的部分，我可以帮你详细讲解一下。小白:太好了，那能先简单介绍一下TCP拥塞控制算法吗？大牛:当然。TCP拥塞控制算法是为了解决在网络拥塞时，防止网络出现过多的数据包丢失或延迟，从而保证数据传输的可靠性。主要有四种算法，分别是慢启动、拥塞避免、快速恢复和快速重传。小白:那什么是慢启动呢？大牛:慢启动是指在连接刚建立时，TCP首先以一个比较小的拥塞窗口值开始发送数据。每经过一个往返时间RTT，拥塞
我正在解决一些通信问题，在网络跟踪中我偶尔会遇到TCP序列错误。我得到的一个例子是:服务器到客户端:Seq=3174，Len=50客户端到服务器:Ack=3224服务器到客户端:Seq=3224，Len=50客户端到服务器:Ack=3224服务器到客户端:Seq=3274，Len=10客户端到服务器:Ack=3224，SLE=3274，SRE=3284数据包4和5几乎同时记录在跟踪(来自客户端和服务器之间的路由器)中，因此它们很可能在传输过程中交叉。TCPsession不同步，客户端丢失了来自服务器的最后两次传输。这两个数据包应该已经重传，但他们没有，跟踪中的下一个日志是数据包6后24
我在Linux上工作。我有一个HTTP客户端，它从HTTP服务器请求一些数据。HTTP客户端是用C编写的，HTTP服务器是用perl编写的。我想在客户端模拟TCP重传超时。我假设正常关闭套接字不会导致客户端重新传输请求。所以我尝试了以下场景:一旦收到HTTPGET请求就退出服务器。但是，我注意到一旦应用程序退出，套接字仍然正常关闭。我看到服务器向客户端发起FIN.ACK消息，即使应用程序没有在套接字上调用“关闭”。我在用C程序编写的简单TCP服务器和客户端上也注意到了这种行为。服务器不会对客户端的GET请求发送任何响应。在这种情况下，我注意到服务器仍然发送了FIN、ACK。似乎在这些情
