小楼一夜听春雨，深巷明朝卖杏花

我们通过了解TCP各个状态，可以排除和定位网络或系统故障时大有帮助。

初步认为是服务器资源不⾜了，但经反复测试，⼀旦连接上，不断点击同⼀个页⾯上不同的链接，都能迅速打开，这种现象就是说明apache最⼤连接数已经满了，新的访客只能排队等待有空闲的链接，⽽如果⼀旦连接上，在keeyalive 的存活时间内（KeepAliveTimeout，默认5秒）都不⽤重新打开连接，因此解决的⽅法就是加⼤apache的最⼤连接数。然后wc -l统计。约8K个进程，⽀持2W⼈同时访问应该是没有问题的（能保证其中8K的⼈访问很快，其他的可能需要等待1、2秒才能连上，⽽⼀旦连上就会很流畅）

当server连续发送4个报文给client，而第三个报文丢失的时候，而我们的server是在第七步收到ACK，这个ACK是说第三个报文没有收到，接下来server怎么处理，这就有两种方式，第一种采用保守和乐观的方式，所谓乐观就是认为第四个帧应该是被对方收到了，seq序号是用累计确认的方式的，所以client没有办法去告诉server其实第四个帧我是收到了，server尽量乐观，所以仅仅发送第三个部分。所以积极的将所有的段都发出去，带来的问题是可能浪费带宽，因为其实第4个报文是发送给client的。

OSI 模型下的七层 LB 与四层 LB由于七层负载均衡可以解析到应用层协议，所以它可以做许多的事情。四层负载均衡主要面对的是传输层协议，理论上只能解析到udp和tcp层的协议。

连续发送了pkt 3 4 5 6，其中第5个报文丢失了，我们收到ACK4的时候这不是一个失序的，当收到ACK5的时候，它已经重复了一次，当发pkt7 pkt8的时候，我们再次接收到了ACK5，除了第一次正常的接收到之外，后面还重复了三次，从重复三次以后，我们将进入快速重传，所谓快速重传就是将连续三次重复丢失了ACK5，我们就重发pkt5。如果我们的报文丢失了，后续发送的报文，都会到达接收端，这样接收端会发送连续的ack，这些ACK都是确认的丢失的报文段。若报文重复，将会产生少量的失序 ACK 段。

最初以以4个MSS作为最初的拥塞窗口，以2倍的速度改为4 8 16，到16这收到ack之后就会升到32 64，到波峰的时候还没有达到最初的慢启动阈值的时候就开始出现丢包了，此时我们的拥塞窗口是64，所以新的慢启动阈值变为64的一半32，然后重新从4个mss作为初始的拥塞窗口，再进入慢启动，这里到32的时候进入拥塞避免，再次发生丢包的时候又重新进入了慢启动，拥塞避免。它定义了慢启动阈值，当拥塞窗口达到了阈值之后，就不以指数的方式，就改为线性的方式，，到了相应的阈值之后，再改为拥塞避免算法，所以。

由于TCP协议向应用层提供不定长的字节流发送方法，使得TCP协议先天性的就有意愿占满网络中的整个带宽，但是网络中许多TCP连接同时去试图占满整个带宽的时候就有可能发生恶心拥塞事件，而TCP的拥塞控制算法则是非常有必要的，能够有效的降低网络当中的拥塞，提升所有TCP的发送速度。当R3发生丢掉过载的数据包的时候，R3的队列也会非常的长，使得每一个报文在网络当中呆的时间也会更加长，RTT时延也会过长，当轻度拥塞的时候吞吐量已经下降了，当重度拥塞的时候网络是非常糟糕的。慢启动，拥塞避免，快速重传，快速恢复。...

a、可靠的实现 TCP 全双工连接的终止：四次挥手关闭 TCP 连接过程中，最后的 ACK 是由「主动关闭连接」的一端发出的，如果这个 ACK 丢失，则，对方会重发 FIN 请求，因此，在「主动关闭连接」的一段，需要维护一个 time_wait 状态，处理对方重发的 FIN 请求；短时间后，所有的 TIME_WAIT 全都消失，被回收，端口包括服务，均正常。1.TCP 连接建立后，「主动关闭连接」的一端，收到对方的 FIN 请求后，发送 ACK 响应，会处于 time_wait 状态；

如果没有TIME-WAIT状态或者TIME-WAIT状态非常短，就有可能发生下面的事情，比如第三个报文其实不是丢失了，它只是在网络当中被延迟了，现在它突然收到了，就会对接收方造成数据错乱的影响，所以time-wait是有保护效果的，它保持不让延迟发过来的数据来扰乱我的新连接。tcp_tw_reuse只是作为客户端可以使用，这个时候风险是比较小的，作为服务器端也可以使用time-wait状态的端口，就一定会被延迟的报文还有重复的报文影响新的连接，造成数据的混乱，所以通常是不开启的。...

当然了，虽说Linux实际按照TCP/IP模型，实现了网络协议栈，但在平时的学习交流中，我们习惯上还是用OSI七层模型来描述。比如，说到七层和四层负载均衡，对应的分别是OSI模型中的应用层和传输层（而它们对应到TCP/IP模型中，实际上是四层和三层）。为了解决网络互联中异构设备的兼容性问题，并解耦复杂的网络包处理流程，OSI模型把网络互联的框架分为应用层、表示层、会话层、传输层、网络层、数据链路层以及物理层等七层，每个层负责不同的功能。然后封装上该层的协议头，再发送给下一层。.........

在发送了关闭连接的请求之后，A状态就变为了FIN-WAIT-1，B发送确认之后变为CLOSE-WAIT，变成了关闭并且等待。现在A不能向B发送数据的，但是B可以向A发送数据，B发送释放连接的请求，这个时候FIN标记位为1，确认号还是u+1，然后序号是w，A收到并且确认号是w+1。A计算机传输完了数据，传完之后要发出释放连接的数据包，这个TCP的FIN标记位为1，序号为u，B收到之后就通知应用程序A发完了，A不给B发了，B收到之后给它发送确认，确认号是u+1，序号是v，确认标记位为1。............

一般都会去过滤，比如显示某块网卡的流量，就是要指定具体的网卡，这样就可以知道某个网卡的流量具体是多少，如果你做了双网卡的绑定，那么就是使用bond0）比如某个主机疯狂的向另外一个主机发送数据包，我们不清楚它往哪个主机发，通过iftop就可以清晰的看到通过这块网卡的和某个指定主机它们发送和接受数据是什么样的。通过这两列可以很清楚的看出，本机和对应的主机，它们发送数据和接受数据的状态是什么样的。最右边的是显示外部的ip连接到本机，2s内，10s内，40s内的一个平均流量值，显示不同时间段的流量值。...

•net.ipv4.tcp_syn_retries=6主动建立连接时，发SYN的重试次数（客户端发完syn，其实就进入了syn_sent状态，在syn_sent状态的时候，对于linux上面的负载均衡，或者向其他服务器建立大量连接的时候，也可以通过syn_retries来设置重发syn的重试次数）•net.ipv4.tcp_synack_retries被动建立连接时，发SYN/ACK的重试次数（当我们发送SYN/ACK之后，长时间没有得到ack响应，我们可能要重发SYN/ACK的重试次数）.........

TCP是面向字节流的协议，它不限制应用层传输消息的长度，实际上在TCP之下的网络层和数据链路层，由于发送报文使用的内存是有限的，所以一定会限制报文的长度。因此TCP必须将其从应用层那里接收到任意长度的字节流切分为许多报文段，拆分报文段的依据是什么呢？下面来看看如何基于mss最大报文段大小来进行TCP报文段的拆分。 如果直接使用TCP socket库去编程的话，client向server去建立连接的时候，需要建立一个socket，会去调用connect方法，server端会在accept成功建立连接之后

- 数据偏移指的是TCP报文段的数据起始处距离TCP报文段的起始处有多远。- 6个控制位介绍如下| 控制位 | **作用** || ------ | :----------------------------------------------------------- || ACK | 置1时表示确认号合法，为0的时候表示数据段不包含确认信息，确认号被忽略 || PSH | 置1时请

每次发一个段，都有一个计时，什么时候发的，超时之后自动重传，那么这个超时时间的选择也是需要调整的，也得判断一下多长时间为超时。发送了一个tcp的段，在规定的时间内没有收到确认，那么这个段就自动的重发。重传超时的时间也需要动态的调整，也需要进行判断。TCP往返传输时间（RTT） 的测量可以采用两种方法：（1）TCP Timestamp选项（tcp首部的选项）（2）重传队列中数据包的TCP控制块（b计算机和a计算机通信，发起一个建立连接的请求，这边给你一个响应，一去一回就知道往返时间了）可以看到抓的包是有时间标

应用程序在通信的时候，也即是进程在通信的时候，浏览器访问web站点，HTTP协议要想发送的话，我这个计算机要先去调用TCP协议，先建立连接，发送tcp建立连接的请求，服务端给我一个确认，我再给服务器一个确认。需要发三个数据包。建立了TCP连接之后，再发送http的报文，web站点再用这个连接将网页返回给我的客户端。当所有的通信都结束了，那么浏览器还要释放连接。tcp在通信之前需要发送3个数据包来建立连接，释放连接需要发送4个数据包。之前说的可靠传输，流量控制，拥塞避免，这些都是在通信过程当中用到的技术。建立

一般面试的时候我问这两个协议的区别，大部分人会回答，TCP 是面向连接的，UDP 是面向无连接的。什么叫面向连接，什么叫无连接呢？在互通之前，面向连接的协议会先建立连接。例如，TCP 会三次握手，而 UDP 不会。为什么要建立连接呢？你 TCP 三次握手，我 UDP 也可以发三个包玩玩，有什么区别吗？所谓的建立连接，是为了在客户端和服务端维护连接，而建立一定的数据结构来维护双方交互的状态，用这样的数据结构来保证所谓的面向连接的特性。例如，TCP 提供可靠交付。通过 TCP 连接传输的数据，无差错、不丢失、不

通信两端的TCP协议在发数据包的时候要感受网络是否畅通，如果网络出现了阻塞，出现了丢包现象，他们会自动的降低发送速度，如果网络畅通了会提高发送速度。拥塞是一个动态的，比如上下班会出现堵车现象，是大家的车都往路上跑引起的阻塞。左边的计算机和右边的计算机都要进行通信，通信的流量都过这一条链路，链路的带宽都是有限的，比如1G，千兆带宽，从一边涌入了700M的带宽，从另外一边涌入了600M带宽，都要过这1000M的链路，超过了最大值，肯定有部分数据包就丢掉了。如果出现丢包了，还是什么都不管，该怎么发怎么发，发了20

TCP是面向连接的传输层协议。（在正式传数据之前需要发3个数据包，这叫三次握手，建立了连接之后协商参数，比如缓存多大，接受的每个段是多少个字节）每一条TCP连接只能有两个端点（end point），只能是点对点的（一对一，多播和广播都是不行的）。TCP提供可靠交付的服务。也就是说，通过TCP连接传送的数据，无差错、不丢失、不重复且按序发送。TCP提供全双工通信。（一但发送端和接收端建立了连接，那么可以使用这个连接双向通信）面向字节流。TCP中的“流”（steam）指的是流入到进程或从进程流出的字节序列。（不

TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。TCP会话的双方都各自维护一个发送窗口和一个接收窗口。接收窗口大小取决于应用、系统、硬件的限制。发送窗口则取决于对端通告的接收窗口。接收方发送的确认报文中的window字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将接收方的确认报文window字段设置为 0，则发送方不能发送数据。TCP头包含window字段，16bit位，它代表的是窗口的字节容量，最大为65535。这个字段是接收端告诉发送端自己还有多少缓

上面可以看到收到了1 2 3 4给它一个确认，ack=401要它发送第5个了，1，2，3就不需要发确认了，说明已经收到了，发最后一个就行。之后收到了5，6，7丢了，8也收到了，返回确认告诉它该发601个字节了，如果不支持选择性确认的话，那么会将7，8，9，10都发一遍，也就是将601后面的全部发一遍。而有了选择性确认，在返回确认的时候，会告诉边界，也就是头和尾，哪些段收到了，那么8这个段就不需要重发了。连续ARQ协议和滑动窗口协议都采用累积确认的方式接收端收到了1-49640这些字节，然后从51101个字

UDP协议的特点用户数据报协议（UDP）只在IP的数据报服务之上增加了很少一点功能，就是复用和分用的功能以及差错检测的功能，这里所说的复用和分用，就是使用端口标识不同的应用层协议。UDP协议将应用程序要传的内容原封不动的封装之后发走，不加编号和分段 UDP的主要特点是： UDP是无连接的，即发送数据之前不需要建立连接（当然发送数据结束时也没有连接可释放），因此减少了开销和发送数据之前的时延。（计算机域名解析用的就是UDP协议，如果发的数据包失败了，解析没有成功就再发一遍，尝试多次，直到失败或者成功

前面的可靠传输的工作原理，比较概括一些，比如停止等待协议，连续ARQ和滑动窗口，以字节为单位的滑动窗口技术其实就是详细的说连续ARQ和滑动窗口是怎么实现的。应用程序要将文件传输给另外一个计算机，其实这个文件是以字节流的方式往缓存里面放，在缓存里面将字节分段， 分段，每个序号为分段中的第一个。 a和b计算机通信的时候要建立连接，b计算机告诉a计算机这边的接受窗口是400个字节，最大支持的报文段mss是100个字节，这是b计算机告诉a计算机的，400个字节就是接受窗口。这个时候a在缓存里面设置一个发送窗口，这

其实网络当中的流量，绝大多是应用程序之间的通信产生的。比如访问网站的流量，看电影的流量等等。程序在电脑上面的表现为进程，其实访问网络上面的服务就是进程和进程的通信。网络其实是不可靠的，比如图片的发送被分为一个一个的数据包来传，如果链路上面传的数据包多，路由器处理不了，这个路由器就将这个数据包直接丢弃，那么接收端接收到的图片就是不完整的，这是不允许的。 网站要将网页传输给浏览器，将网页放到传输层，在传输层分段进行编号，分段之后给每个段添加IP地址，源地址目标地址，这就形成了数据包。接收端收到之后放到缓存里面，

源端口和目的端口各占2个字节，分别写入源端口号和目的端口号。和UDP一样，使用端口号标识不同的应用层协议TCP的首部是变长的，其中有20个字节是固定的，一行有4个字节，源端口和目标端口分别占用2个字节，全部为1的话，那么取值是65535，也就是端口号最大是65535。序号占4字节。序号范围是[0,232-1]，共232（即4 294 967 296）个序号，首部中的序号字段值则指的是本报文段所发送的数据的第一个字节的序号。A计算机向B计算机传文件，传文件那么文件就写到缓存里面，在缓存里面的字节就开始分段，比

停止等待协议，它有个问题就是信道利用率低，TD：A发数据的时间 RTT：往返时间 TA：收到确认之后，等了一段时间，再发送第二个分组可以看到往返时间越大，这个信道利用率就越低。为了提高信道的利用率那就是使用流水线传输，发数据的时候不要一个一个的发，比如连续的发出10个，然后告一段落，然后等着回复，如果都收到了回复，那么接着发11，这样的话，信道利用率就高了，就像机关枪一样，之前是步枪，打一次需要上膛一下子弹，现在一梭子下去。停止等待。发送方每次只发送一个分组。在收到确认后再发送下一个分组。编号。对发送的每个

上面是两种可靠传输的实现方法，第一种是停止等待协议，第二种是改进的停止等待协议也就是连续ARQ协议和滑动窗口协议，这两种协议相结合组成的改进的停止等待协议。现在使用的是连续ARQ协议和滑动窗口协议，只有知道停止等待协议才能知道连续ARQ协议和滑动窗口协议的优点。理想的传输条件有以下两个特点∶1.传输信道不产生差错。（不会出现乱序的现象，或者丢包）2.不管发送方以多快的速度发送数据，接收方总是来得及处理收到的到数据。（接收方处理不过来，让发送方发慢一点，这个时候就需要TCP协议来实现可靠传输和流量控制）在这样

后台开发，netstat命令总是绕不过，不仅工作中经常用过，面试也是考的多。netstat命令，对应的选项比较多，功能比较强大。netstat 常用来查看，后台服务进程的相关状态。netstat 可以用来打印网络连接、路由表、连接的数据统计。下面我们来学习一下。

通常传输层协议加一个端口号来标识一个应用层协议。TCP通过端口号标识上层是什么协议，同理UDP也是通过端口来区分上层协议。HTTP默认使用TCP的80端口。 FTP默认使用TCP的21端口。 SMTP默认使用TCP的25端口。 POP3默认使用TCP的110端口。 HTTPS默认使用TCP的443端口。 DNS使用UDP的53端口。 远程桌面协议（RDP）默认使用TCP的3389端口。 Telnet使用TCP的23端口。 Windows访问共享资源使用TCP的445端口。 微软SQ

船宿层和应用层是面向用户的，帮用户实现功能的，同时传输层也是面向通信功能的，可见这一层是承上启下的这一层。其实网络当中的流量，绝大多是应用程序之间的通信产生的。比如访问网站的流量，看电影的流量等等。程序在电脑上面的表现为进程，其实访问网络上面的服务就是进程和进程的通信。进程之间的通信就要使用各种各样的协议。应用层协议有时候要求网络是可靠的，客户端发送的请求必须得收到，网络其实是不可靠的，比如图片的发送被分为一个一个的数据包来传，如果链路上面传的数据包多，路由器处理不了，这个路由器就将这个数据包直接丢

网络性能评估主要是监测网络带宽的使用率，将网络带宽利用最大化是保证网络性能的基础，但是由于网络设计不合理、网络存在安全漏洞等原因，都会导致网络带宽利用率低。要找到网络带宽利用率低的原因，可以对网络传输进行监控，此时就需要用到一些网络性能评估工具，而iperf就是这样一个网络带宽测试工具。.........

今天我们将从稳定性角度深挖 TCP 协议的运作机制。如今，大半个互联网都建立在 TCP 协议之上，我们使用的 HTTP 协议、消息队列、存储、缓存，都需要用到 TCP 协议——这是因为 TCP 协议提供了可靠性。简单来说，可靠性就是让数据无损送达。但若是考虑到成本，就会变得非常复杂——因为还需要尽可能地提升吞吐量、降低延迟、减少丢包率。...

TCP 的握手和挥手TCP 是一个连接导向的协议，设计有建立连接（握手）和断开连接（挥手）的过程。TCP 没有设计会话（Session），因为会话通常是一个应用的行为。TCP 协议的基本操作TCP 协议有这样几个基本操作：如果一个 Host 主动向另一个 Host 发起连接，称为 SYN（Synchronization），请求同步 如果一个 Host 主动断开请求，称为 FIN（Finish），请求完成 如果一个 Host 给另一个 Host 发送数据，称为 PSH（Push），数.