系统运输
传输控制协议( TCP )协议与IP协议一起生成。 其实，两者最初是一个协议，后来又分为网络层的IP和传输层的TCP。 如已经在UDP协议中所述，UDP协议是IP协议传输层中的“傀儡”，用来实现分组通信。 TCP协议实现了“流”形式的通信。
TCP的内容非常丰富。 我不能在一篇文章里结束TCP。 本文主要讨论了TCP协议的以下几个方面。
“流”通信的含义和实现方法
实现可靠传输的方法
使用滑动窗提高效率
“流”通信
TCP协议是传输层协议，实现从端口到端口的通信。 并且，TCP协议对文本流( byte stream )的通信进行了虚拟化。 在Linux文本流中，论述了计算机数据的本质是规则的0/1序列(如果是byte单位则称为文本流)。 计算机的功能是保存和处理文本流。 CPU memory存储设备实现文本流在同一台计算机内部的加工处理。 通过屏幕和键盘等几个IO，文本流实现了人机交互。 另外，如果网络通信可以在不同的计算机之间进行文本流的交换，就可以与整个计算机系统的数据处理方式对接。
IP协议(请参见TCP/IP协议细节03，05 )和UDP协议以数据包方式发送，之后发送的数据包可能会提前到达，不保证数据的到达顺序。 TCP协议确保数据到达的顺序与文本流的顺序一致。 当计算机从TCP协议接口读取数据时，这些数据是已经按顺序排列的“流”。 例如，有一个从本地主机发送到远程主机的大文件。 如果通过“流”接收，则可以在接收的同时将文本流保存到文件系统。 这样，在“流”接收完成之前，硬盘写入操作也将完成。 如果采用了UDP的传输方式，为了组装成大文件，需要等待所有的数据到达。 在这种情况下，必须使用大量的计算机资源来存储到达的数据。 在所有数据到达之前无法开始处理。
“流程”的重点是顺序( order )，但要实现这个并不容易。 由于TCP协议基于IP协议，因此最终的数据传输是以IP数据包为单位进行的。 如果一个文本流很长，则整个文本不能流至一个IP数据包。 这样的话，有可能超过MTU。 因此，将TCP协议封装到IP分组中的不是整个文本流，而是由TCP协议规定的片段( segment )。 与以前的一个IP或UDP包一样，一个TCP片段也同样分为两部分：头部( header )和数据( payload )。 “片段”名称通常有助于引起注意，因为它不是完整的文本流。 整个文本流按顺序划分为段，每个段位于TCP段的数据部分。 一个TCP片段封装在整个IP中继路径的最小MTU以下的IP数据包中，避免了痛苦的碎片。
(文本流碎片发生在发送主机上，碎片发生在网络中的路由器上。 路由器处理很多道路的通信，所以相当忙。 通过在发送主机上事先对文本流进行分段，可以避免路由器上的碎片，大幅度减轻网络负荷)
片段和编号
TCP片段的“头”( header )包含该片段的序列号( sequence number )。 因此，接收的计算机可以知道接收的片段在原始文本流中的顺序，并且接着可以知道为了形成流需要接收哪些片段。 例如，当接收到段1、段2、段3时，接收主机开始期待段4。 当接收到不按顺序的分组(例如，片段8 )时，接收方的TCP模块可拒绝接收，这确保了提供给接收主机的信息是按顺序的“流”。
可靠性
片段号码这个初步想法并不能解决我们所有的问题。 由于IP协议不可靠，因此在传输IP数据包时可能会出现错误或丢失。 另一方面，IP传输是“Best Effort”式的，一旦发生异常情况，我们的IP数据包很容易被丢弃。 另一方面，当out-of-order片段到达时，根据上面的说明，接收主机不会接收到。 这样，如果错误、丢失或拒绝的碎片被协作破坏，接收主机可能会收到充满“漏洞”的文本流。
请把洞填上
TCP修复方法是，每次收到顺序正确的片段时，都将一个特殊的TCP片段发送到发送方，即另一个连接的片段，以知道发送方。 我已经接收到那个片段了。 这个特殊的TCP片段称为ACK回复。 在1个段编号为l的情况下，与ACK对应地返回回复编号L 1，即接收侧期待接收的下一个发送段的编号。 如果发送方等待了一定时间还没有收到ACK的回复，则估计以前发送的片段一定有异常。 发送方重复发送( retransmit )发生异常的片段，并等待ACK的回复。 如果还没有收到，则重复发送原始片段……直到收到与该片段对应的ACK的回复(回复编号为L 1的ACK )为止。
终于收到了ACK的发送主机
当发送方收到ACK回复时，它会发现里面的回复号是L 1，即发送方下一个应该发送的TCP片段号。 发送方估计以前的段被正确接收，发行L 1段。 ACK回复也可能丢失。 对发送方来说，这等同于接收方拒绝发送ACK回复。 发送方重复发送，但接收方接收到已知通过的片段，推测ACK回复已丢失，重新发送ACK回复。
通过ACK响应和重传机制，TCP协议使片段传输可靠。 尽管机箱是不可靠的IP协议，但TCP协议以“永不放弃的精神”，不断尝试，最终成功。 (技术也很感人)
面对“挫折”的TCP协议态度： never give up
TCP协议和UDP协议两个极端了。 TCP协议复杂但可靠，UDP协议轻量级但不可靠。 在处理异常时，TCP极端负责，而UDP却一副无所谓的样子。 顺便试着把UDP协议变成“黑”吧。
同样面临“挫折”的UDP的态度： who cares…
滑动窗
以上工作方式中，发货方采取的是发送-等待ack -发送-等待ack…的单线工作方式。 这样的工作方式叫做停止和等待。 stop-and-wait实现了TCP通信的可靠性，但同时牺牲了网络通信的效率。 在等待ACK的时候，我们的网络处于空闲状态。 我们想要一种可以同时发送多个片段的方法。 然而，如果同时接收多个片段，则因为IP分组的重发是无序的，所以乱序的片段，即最后接收的片段可能最先到达。 在停止和等待的机制中，无序的碎片被完全拒绝，这也是低效的。 毕竟，无序的碎片只是早到的碎片。 也可以保存在缓存中，等到前面的片段被补充后，再放在后面。 但是，如果片段顺序混乱，该片段太快“混乱”，就会长时间占用缓存。 解决这个问题需要折中的方法。 利用缓存留下几个“不那么混乱”的片段，希望能在时间内补充上一个片段。 (暂时不处理，但发送适当的ACK。 )对于“乱”比较强的片段，拒绝它们(不处理，也不发送对应的ACK )。
总是有一些“越轨”的片段
为了解决上述问题，滑动窗口既适用于接收端，也适用于发送端。 发送方和接收方分别有滑动窗。 如果剪辑位于滑动窗口中，则TCP正在处理剪辑。 滑块窗口中可能有多个段。 这意味着可以同时处理多个块。 滑块窗口越大，滑块窗口越大，同时处理的段数就越多。 当然，计算机需要为滑动窗口分配更多的缓存。
同时处理多个片段
假设滑动窗口可以容纳三个块，并假设块从左到右排列。 对于发送方，滑动窗口的左侧是已经发送的ACK片段序列，并且滑动窗口的右侧是未发送的片段序列。 滑动窗口的中间片段，例如，发送片段5、6、7，以等待相应的ACK。 如果收到片段5的确认，滑动窗口将向右移动。 这样，新的片段从右侧进入滑动窗口内，送出，进入等待状态。 在收到片段5的确认之前，滑动窗口不会移动。 即使收到了片段6和7的ACK。 因此，滑动窗口左侧的序列可确保为根据已经发射并接收到ACK的顺序的片段序列。
对于接收方来说，滑动窗口的左侧是正确接收和由ACK返回的片段(例如片段1、2、3、4 )，也就是正确接收的文本流。 幻灯片窗口显示您希望接收的片段。 例如，片段5、6和7 )。 同样，如果片段6、7先到达，则滑动窗不会移动。 当片段5先到达时，滑动窗口向右移动，等待接收新片段。 如果显示幻灯片9等非幻灯片9的剪辑，幻灯片9将拒绝接收。
以下视频试图模拟可容纳三个碎片的滑动窗(固定大小)的工作过程。
上面的视频是我用Python和matplotlib包做的。 蓝点表示片段，红点表示ACK。 为了说明无序的碎片，我故意让碎片和ACK的速度在两个值中随机选择。
随着滑动窗的滑动，可以看到越来越多的片段被正确发送。 利用滑动窗口，我们在一定程度上实现了无序数据的缓存。 但是，过于无序的数据仍然会被拒绝。 我们之前说的stop-and-wait的工作方式，相当于在发送方和接收方的滑动窗上只能收纳一个片段。
可以看出，今后TCP协议中将有实时调整滑动窗口大小的算法，以实现最佳效率。
总结
TCP协议和UDP协议两个极端了。 TCP协议复杂但可靠，UDP协议轻量级但不可靠。 在处理异常时，TCP极端负责，而UDP却一副无所谓的样子。 在TCP中，段和编号实现了顺序。 确认和重发实现了可靠性的滑动窗口可以更有效地运行上述机制。 Never give up，这就是TCP协议的态度。
转载： http://www.code123.cc/1282.html
详情请访问云服务器、域名注册、虚拟主机的问题，请访问西部数码代理商官方网站： www.chenqinet.cn