TCP那些事儿

目录：

以前我也认为TCP是相当底层的东西，我永远不需要去了解它。虽然差不多是这样，但是实际生活中，你依然可能遇见和TCP算法相关的bug，这时候懂一些TCP的知识就至关重要了。（ 本文也可以引申为，系统调用， *** 作系统这些都很重要，这个道理适用于很多东西 ）
这里推荐一篇小短文， 人人都应该懂点TCP

使用TCP协议通信的双方必须先建立TCP连接，并在内核中为该连接维持一些必要的数据结构，比如连接的状态、读写缓冲区、定时器等。当通信结束时，双方必须关闭连接以释放这些内核数据。TCP服务基于流，源源不断从一端流向另一端，发送端可以逐字节写入，接收端可以逐字节读出，无需分段。

需要注意的几点：

TCP状态（11种）：
eg

以上为TCP三次握手的状态变迁

以下为TCP四次挥手的状态变迁

服务器通过 listen 系统调用进入 LISTEN 状态，被动等待客户端连接，也就是所谓的被动打开。一旦监听到SYN（同步报文段）请求，就将该连接放入内核的等待队列，并向客户端发送带SYN的ACK（确认报文段），此时该连接处于 SYN_RECVD 状态。如果服务器收到客户端返回的ACK，则转到 ESTABLISHED 状态。这个状态就是连接双方能进行全双工数据传输的状态。
而当客户端主动关闭连接时，服务器收到FIN报文，通过返回ACK使连接进入 CLOSE_WAIT 状态。此状态表示——等待服务器应用程序关闭连接。通常，服务器检测到客户端关闭连接之后，也会立即给客户端发送一个FIN来关闭连接，使连接转移到 LAST_ACK 状态，等待客户端对最后一个FIN结束报文段的最后一次确认，一旦确认完成，连接就彻底关闭了。

客户端通过 connect 系统调用主动与服务器建立连接。此系统调用会首先给服务器发一个SYN，使连接进入 SYN_SENT 状态。
connect 调用可能因为两种原因失败：1 目标端口不存在（未被任何进程监听）护着该端口被 TIME_WAIT 状态的连接占用（ 详见后文 ）。2 连接超时，在超时时间内未收到服务器的ACK。
如果 connect 调用失败，则连接返回初始的 CLOSED 状态，如果调用成功，则转到 ESTABLISHED 状态。
客户端执行主动关闭时，它会向服务器发送一个FIN，连接进入 TIME_WAIT_1 状态，如果收到服务器的ACK，进入 TIME_WAIT_2 状态。此时服务器处于 CLOSE_WAIT 状态，这一对状态是可能发生办关闭的状态（详见后文）。此时如果服务器发送FIN关闭连接，则客户端会发送ACK进行确认并进入 TIME_WAIT 状态。

流量控制是为了控制发送方发送速率，保证接收方来得及接收。

接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。

如果网络出现拥塞，分组将会丢失，此时发送方会继续重传，从而导致网络拥塞程度更高。因此当出现拥塞时，应当控制发送方的速率。这一点和流量控制很像，但是出发点不同。 流量控制是为了让接收方能来得及接收，而拥塞控制是为了降低整个网络的拥塞程度。

TCP 主要通过四种算法来进行拥塞控制： 慢开始、拥塞避免、快重传、快恢复。

在Linux下有多种实现，比如reno算法，vegas算法和cubic算法等。
发送方需要维护一个叫做拥塞窗口（cwnd）的状态变量，注意拥塞窗口与发送方窗口的区别：拥塞窗口只是一个状态变量，实际决定发送方能发送多少数据的是发送方窗口。
为了便于讨论，做如下假设：

发送的最初执行慢开始，令 cwnd=1，发送方只能发送 1 个报文段；当收到确认后，将 cwnd 加倍，因此之后发送方能够发送的报文段数量为：2、4、8

注意到慢开始每个轮次都将 cwnd 加倍，这样会让 cwnd 增长速度非常快，从而使得发送方发送的速度增长速度过快，网络拥塞的可能也就更高。设置一个慢开始门限 ssthresh，当 cwnd >= ssthresh 时，进入拥塞避免，每个轮次只将 cwnd 加 1。

如果出现了超时，则令 ssthresh = cwnd/2，然后重新执行慢开始。

在接收方，要求每次接收到报文段都应该对最后一个已收到的有序报文段进行确认。例如已经接收到 M1 和 M2，此时收到 M4，应当发送对 M2 的确认。

在发送方，如果收到三个重复确认，那么可以知道下一个报文段丢失，此时执行快重传，立即重传下一个报文段。例如收到三个 M2，则 M3 丢失，立即重传 M3。

在这种情况下，只是丢失个别报文段，而不是网络拥塞。因此执行快恢复，令 ssthresh = cwnd/2 ，cwnd = ssthresh，注意到此时直接进入拥塞避免。

慢开始和快恢复的快慢指的是 cwnd 的设定值，而不是 cwnd 的增长速率。慢开始 cwnd 设定为 1，而快恢复 cwnd 设定为 ssthresh。

  发送端的每个TCP报文都必须得到接收方的应答，才算传输成功。

  TCP为每个TCP报文段都维护一个重传定时器。
  发送端在发出一个TCP报文段之后就启动定时器，如果在定时时间类未收到应答，它就将重发该报文段并重置定时器。

  因为TCP报文段最终在网络层是以IP数据报的形式发送，而IP数据报到达接收端可能是乱序或者重复的。TCP协议会对收到的TCP报文进行重排、整理，确保顺序正确。

TCP报文段所携带的应用程序数据按照长度分为两种： 交互数据 和 成块数据

对于什么是粘包、拆包问题，我想先举两个简单的应用场景：

对于第一种情况，服务端的处理流程可以是这样的：当客户端与服务端的连接建立成功之后，服务端不断读取客户端发送过来的数据，当客户端与服务端连接断开之后，服务端知道已经读完了一条消息，然后进行解码和后续处理。对于第二种情况，如果按照上面相同的处理逻辑来处理，那就有问题了，我们来看看 第二种情况 下客户端发送的两条消息递交到服务端有可能出现的情况：

第一种情况：

服务端一共读到两个数据包，第一个包包含客户端发出的第一条消息的完整信息，第二个包包含客户端发出的第二条消息，那这种情况比较好处理，服务器只需要简单的从网络缓冲区去读就好了，第一次读到第一条消息的完整信息，消费完再从网络缓冲区将第二条完整消息读出来消费。

第二种情况：

服务端一共就读到一个数据包，这个数据包包含客户端发出的两条消息的完整信息，这个时候基于之前逻辑实现的服务端就蒙了，因为服务端不知道第一条消息从哪儿结束和第二条消息从哪儿开始，这种情况其实是发生了TCP粘包。

第三种情况：

服务端一共收到了两个数据包，第一个数据包只包含了第一条消息的一部分，第一条消息的后半部分和第二条消息都在第二个数据包中，或者是第一个数据包包含了第一条消息的完整信息和第二条消息的一部分信息，第二个数据包包含了第二条消息的剩下部分，这种情况其实是发送了TCP拆，因为发生了一条消息被拆分在两个包里面发送了，同样上面的服务器逻辑对于这种情况是不好处理的。

我们知道tcp是以流动的方式传输数据，传输的最小单位为一个报文段（segment）。tcp Header中有个Options标识位，常见的标识为mss(Maximum Segment Size)指的是，连接层每次传输的数据有个最大限制MTU(Maximum Transmission Unit)，一般是1500比特，超过这个量要分成多个报文段，mss则是这个最大限制减去TCP的header，光是要传输的数据的大小，一般为1460比特。换算成字节，也就是180多字节。

tcp为提高性能，发送端会将需要发送的数据发送到缓冲区，等待缓冲区满了之后，再将缓冲中的数据发送到接收方。同理，接收方也有缓冲区这样的机制，来接收数据。

发生TCP粘包、拆包主要是由于下面一些原因：

既然知道了tcp是无界的数据流，且协议本身无法避免粘包，拆包的发生，那我们只能在应用层数据协议上，加以控制。通常在制定传输数据时，可以使用如下方法：

写了一个简单的 golang 版的tcp服务器实例，仅供参考：
例子

参考和推荐阅读书目：

注释：

eg

兴达三菱转以太网模块 之 三菱fx系列plc如何实现Modbus TCP服务器

硬件:三菱fx 一个

兴达易控三菱转以太网 CHNet-FX 一台

CHNet-FX模块太网口它支持8个连接，那么也就是说，当我们plc做ModbusTCP服务器的时候可以有同时8个Modbus TCP客户端。同时和他进行通讯，

我们所需要的一些软件这个以太网调试助手，用来调试这个调试这个plc这个服务器，调试程序，然后我们还会用到这个Modbus poll可以来模拟，ModbusTCP服务器，ModbusRTU主站，以及Modbus ASC主站,

接下来我们继续说一下这个三菱FX5U他实现Modbus TCP这个组态过程,下面就是我们做好的一个这个工程

要实现他这个Modbus TCP他这个过程呢，首先呢第一步用FX5U PLC 与CHNet-FX连接

新建 FX3U/FX3UC 工程，双击导航栏中的连接目标：Connection。
 跳出的选项板后，在计算机侧选择双击“EthernetBoard”选项，随后提醒中点击“是”；在可编程控制器侧双击“PLC Module”；

在随后的跳出的设置中，点击“搜索网络上的 FXCPU(S)”后，会搜索到 CHNet-FX所连接的 FX3UC。

按图中标号依次选择后，最后点击确认；

 在上述中选择好 IP 地址后，点击“通信测试”，即可提示与 FX3UCCPU 连接

5随后即可“在线”选项栏中，进行 PLC 的读取、写入和监视等 *** 作。

Modbus分配地址
PLC配置

口号就是502端口，作为服务器需要设置的参数，

这个逻辑程序D0、D1、D2、D3分别付了初值是K0、K1、K2、K3在初始化的时候我们对D4、D5、D6、D7进行个清零 *** 作设置的这个参数，通讯手段默认ModbusTCP，可编程IP地址就是前面设置的，1921681161端

使用了一个特殊标志位，每一分钟我们会对D0、D1、D2、D3作一个加一 *** 作，看看能不能做一个加一 *** 作，然后会实时的判断，当D0、D1、D2、D3各自的值大于6000的时候分别各自清零，也就说d0d1d2d3的值他会每一分钟都会发生改变，并且d0d1d23d3的纸最终它是会在零到6000之间发生一个变化，（包括0和6000）

这么做的目的是为了客户端去读取PLC的寄存器的时候，D0、D1、D2、D3是变化的方便我们观察变化。这就是一小段逻辑程序

进入程序监视

此时D0、D1、D2、D3分别是0、1、2、3；过1分钟就会进行一下+1 *** 作下面就可以测PLC程序了

先用以太网调试助手进行测试
适配器是PLC通过CHNet-FX网线连接到路由器，电脑通过无线网卡连接到路由器

协议模式：客户端 Client

目标IP：CHNet-FX用户自定义IP地址

当客户无法访问我们的服务器或者访问很慢的时候，我们通常会用到cdn，但是cdn通常只支持>TCP/IP是计算机网络中的两个常用协议，一般无需用户自行设置。
TCP/IP协议并不完全符合OSI的七层参考模型。传统的开放式系统互连参考模型，是一种通信协议的7层抽象的参考模型,其中每一层执行某一特定任务。该模型的目的是使各种硬件在相同的层次上相互通信。这7层是:物理层、数据链路层、网路层、传输层、话路层、表示层和应用层。而TCP/IP通讯协议采用了4层的层级结构，每一层都呼叫它的下一层所提供的网络来完成自己的需求。这4层分别为：
应用层：应用程序间沟通的层，如简单电子邮件传输（SMTP）、文件传输协议（FTP）、网络远程访问协议（Telnet）等。
传输层：在此层中，它提供了节点间的数据传送服务，如传输控制协议（TCP）、用户数据报协议（UDP）等，TCP和UDP给数据包加入传输数据并把它传输到下一层中，这一层负责传送数据，并且确定数据已被送达并接收。
互连网络层：负责提供基本的数据封包传送功能，让每一块数据包都能够到达目的主机（但不检查是否被正确接收），如网际协议（IP）。
网络接口层：对实际的网络媒体的管理，定义如何使用实际网络（如Ethernet、SerialLine等）来传送数据
NTP:做网络时钟（时间来源于互联网，本地不用RTC）
RTP、RTSP:视频监控常用的协议
SNMP:简单网络管理协议（集中式管理）
目的地址与源地址都是MAC（物理地址）；
数据字段长度： 数据的类型（比如0x0800：表示帧里面的“数据”字段是一个IP包）
数据：这里面存放具体的数据包。
IP协议层：IP协议主要目的是为数据的输入、输出网络提供基本算法，为高层协议提供无连接的传送服务。
IP协议层的功能：数据传送、寻址、路由选择、数据报文的分段。
TCP协议：TCP协议是重要的传输层协议，它的目的是为网络上的各节点提供可靠的数据交换。它提供数据端口编号的译码，以识别主机的应用程序，完成数据的可靠传送。
UDP协议:传送层协议，它是无连接不可靠的传送。当接收数据时它并不向发送方提供确认信息，它不提供输入包的顺序，如果出现丢失包或重份包的情况，也不会向发送方发出差错报文，它的执行速度比TCP快，执行时具有较低的开销。
在实际的网络设计中，服务器必须要实现1对多的功能模型；这里就可分为两种服务器：循环服务器与并发服务器。
上面介绍的TCP、UDP通信模型都是循环服务器，TCP的循环服务器与UDP的循环服务器又不同；TCP循环服务器一次只能处理一个客户端的请求。所以一个客户端占住服务器不放，其他的客户端就没法访问服务器，所以在服务器端TCP服务器很少使用循环模式。但是UDP的循环服务器与TCP循环服务器不一样，因为UDP不需要建立连接（TCP建立连接后完全占用服务器），所以UDP的循环服务器直接可以服务多个客户端。
并发服务器：TCP需要使用并发服务器模型才能服务多个客户端。
并发服务器的设计思路是每个客户端的请求并不由服务器直接处理，而是由服务器创建一个子进程来处理。

---