TCP与UDP不同的是TCP有一个欢迎套接字，所有TCP连接都先与欢迎套接字连接，在三次握手后生成一个新的套接字，由特定用户专门使用
运输层协议提供了逻辑通信功能，通过逻辑通信，不同进程的主机似乎相连在一起；实际上是通过很多路由器和多种不同类型的链路相连
运输层协议在端系统实现的，运输层从发送应用程序收到的报文转换为运输层分组，即运输层报文段，实现的方法可能是将应用报文段划分为较小的块，为每块加上一个运输层首部来生成运输层报文段
运输层又将这些报文段传递给网络层，网络层将其封装为网络层分组即数据报，并向目的地发送
网络路由器仅作用于数据报的网络层字段，对运输层报文段不进行检查
在接收端，网络层从数据报提取运输层报文段，再将报文段上交给运输层，运输层处理报文段，再将数据转为应用进程使用
网络层提供了主机之间的逻辑通信
运输层为不同主机的进程之间提供了逻辑通信
类比：
运输层协议只运行在端系统上
TCP和UDP的分组统称为报文段，网络层分组为数据报
网络层协议有一IP协议，即网际协议，为主机提供逻辑通信，服务模型是尽力而为交付服务，尽最大努力交付报文段，但并不做任何确保，实际为不可靠服务，每个主机至少有一个IP地址
TCP和UDP则将主机IP之间的交付服务扩展到进程间的交付，即运输层的多路复用和多路分解
还可以在报文段首部提供差错检查字段来提供完整性检查
运输层提供的最低限度的服务：进程到进程间的数据交付和差错检查
UDP则仅能完成这两种服务，即UDP也是一种不可靠服务
TCP提供可靠数据传输，确保正确地、按序地将数据从发送进程交付给接收进程
还提供拥塞控制（甚至说提供给整个互联网的服务），力求每个通过一条拥塞网络链路的连接平等地共享网络链路带宽
即由网络层提供的主机与主机之间的交付服务扩展到主机上不同进程到进程之间的交付服务
运输层接收到的报文段实际并没有直接交付给进程，而是将数据交付给中间的套接字，而套接字都有唯一标识符
运输层报文段中有部分字段表时出接收套接字，进而将报文段定向到该套接字，此工作称为多路分解
从源主机从不同套接字收集数据库，并为封装上首部信息生成报文段，再将报文段传递到网络层的工作称为多路复用
多路复用要求：
16bit，大小在0 - 65535之间
0 - 1023 是周知端口号，是限制的，保留给周知应用层协议使用
分解服务：每个套接字分配一个端口号，当报文段到达主机时，运输层检查报文段中目的端口号，将其定位到相应套接字，再进入相应的进程，UDP大概是如此，TCP更加复杂
UDP套接字是由一个二元组全面标识的，包含一个目的IP地址和目的端口号
源端口号作为返回地址的一部分，当返回信息时的目的端口号则从源端口号取值
当两个UDP报文段的目的IP地址和目的端口号相同，则不管其源IP地址或源端口号是否相同，都被定为到一个相同的套接字
TCP套接字由四元组标识
当两个TCP报文段有不同的源IP地址或源端口号将被定位到两个不同的套接字，除非报文段携带了初始创建连接的请求，即去访问欢迎套接字
2.7例子
TCP服务器有一个欢迎套接字，在12000端口等待TCP客户的连接建立请求
一条连接建立请求是一个目的端口号为12000，TCP首部的待定“连接建立”位置的TCP报文段，也包含一个由客户选择的源端口号
收到入连接请求报文段后，则定位服务器进程，该进程在12000等待接受连接，服务器进程则创建一个新的套接字
运输层还注意到上述所提的四个值：
新建的套接字被此标识，后续到达的报文段若四个值完全相同则由此套接字负责
综上所述，使用相同的目的端口号可以进行正常通信
UDP从应用进程得到数据后，加上用于多路复用/分解服务的源和目的端口号字段，以及两个小字段后形成的报文段交给网络层，网络层将其封装到一个IP数据报中，尽可能交付，若达到接收主机，则UDP使用目的端口号交付给正确的应用进程
使用UDP时发送方和运输方并没有握手，因此UDP是无连接的
部分应用更适合用UDP：
应用层对数据控制更精细：发送什么数据、何时发送
无须建立连接：更少时延
无连接状态：TCP需要在主机中维护接收、发送缓存，拥塞控制参数及序号和确认号参数，UDP则不需要，能支持更多的活跃客户
分组首部开销小：TCP花费20字节首部开销，UDP仅花费8字节开销
使用UDP的应用是可能实现可靠数据传输的，在应用程序中建立可靠机制
应用层数据占据UDP报文段的数据字段
长度字段指明了包括首部在内的UDP报文段长度，单位字节
提供了差错检测功能，用于确定UDP报文段从源到目的地过程中比特是否发送了改变（链路中的噪声干扰，存储在路由器的时的问题）
因为不是所有链路都提供差错检测，即使所有链路都提供，但经过路由器时可能出错，所以需要在端到daunt数据传输服务提供差错检测，端到端原则
有检测，但对差错回复没有能力，两种实现
实现服务抽象是可靠数据传输协议的责任
rdt可靠数据传输，udt不可靠数据传输
自动重传请求协议：肯定确认与否定确认
差错检测：要求有额外的比特从发送方到接收方，被汇集在rdt2.0数据分组的分组检验和字段中
接收方反馈：肯定确认ACK、否定确认NAK，理论上此分组1比特长，0NAK，1ACK
重传：接收方收到有差错的分组时，发送方将重传该分组文
rdt2.0发送方处于等待ACK或者NAK状态时，不能从上层获得更多数据，因此发送方不会发送新的数据，除非发送方确信接收方已正确接收当前分组，这样的协议被称为停等协议
rdt2.0仍存在问题，ACK或NAK分组可能受损
发送方对接收方进行询问，但此询问出了差错时，接收方难以判断
增加足够的检验和比特，使发送方不仅可以检验，还可以进行恢复
发送方重传分组，然而引起冗余分组，接收方不知道它所发送的ACK或NAK是否被发送方收到，无法判断新分组是最新的还是重传
解决方法：
在数据分组添加新字段，让发送方对数据分组进行编号，即序号，在假设分组不丢失情况下，使用1比特来表示是新分组还是重传分组，即rdt2.1
当接收方收到一个受损分组时，可发送NAK或者上一个分组的ACK（冗余ACK）来向发送方通知没有收到分组
rdt2.2是在有比特差错信道上实现一个午NAK的可靠数据传输协议，与rdt2.1在差别在接收方此时必须包含一个ACK报文确认的分组序号，发送方必须检查接收到的ACK报文中被确认的分组序号
当发送方不知道是分组丢失还是ACK丢失或延时，都采取重传机制，使用基于时间的重传机制，添加一个倒计数定时器，在一个给定时间过期后，中断发送方
发送方要做到：
分组序号在 0 与 1 之间交替，rdt3.0也称比特交替协议
停等协议的有效吞吐量太低
解决：允许发送方发送多个分组而无需确认，看成是填充到流水线中：
影响：
base最早未确认分组
nextseqnum最小未使用序号
已被发送但还未被确认的分组的许可序号范围可以被看成一个在序号范围内长度为N的窗口，所以GBN也称为滑动窗口协议，为了流量控制
分组序号在分组首部的一个固定长度字段中，若比特数是k，则序号范围是[0,2^k - 1]
TCP中为32比特的序号字段，按字节流中的字节进行计数的
GBN发送方需要响应三种类型的事件
上层调用时，先检查发送窗口是否已满，即是否有N个已发送但未被确认的分组，如果未满，则产生一个分组将其发送，并更新变量；如果已满，将数据返回上层，隐式指示该窗口已满，上层等待一会儿再试
实际中发送方更可能缓存这些数据或者使用同步机制允许上层在窗口不满时才调用
收到一个ACK
GBN协议中对序号为n的分组的确认采取累积确认方式，表明接收方收到序号为n的以前且包括n在内的所有分组
超时事件
出现超时，发送方重传所有已发送但未被确认过的分组
发送方仅使用一个定时器，被当做最早的已发送但未被确认的分组的定时器
如果收到一个ACK，但仍有已发送但为被确认的分组，定时器刷新，如果没有已发送但未被确认的分组则停止定时器
接收方：
如果序号为n的分组被收到，且按序，则为分组n发送一个ACK，并将该分组的数据交给上层，在其他情况下丢弃该分组，并将上次收到k的分组重新发送ACK，表示k及k之前的分组收到，k - n的分组需要重新发送
若想要接收n的分组，但接收了n + 1的分组，此时丢弃n + 1分组
因为交付给上层的数据需要按序，虽然浪费，但接收缓存简单，不需要缓存失序分组
因此发送方需要维护窗口的上下边界及nextseqnum的位置
接收方需要维护下一个接收的分组的序号
窗口限制为4，于是发送方连续发送了0，1，2，3，接收方接收了0，1，返回ACK，但2丢失了，接收了3，于是丢弃，而2丢分的ACK还没到ACK，发送方只收到了0，1两个ACK，于是继续发送4，5，接收方收到后继续丢失，当发送方知道了2丢失了，且3，4，5因为失序也被丢失了，于是重传2，3，4，5
单个分组的差错可能引起GBN重传大分组，随着差错率增加，信道中可能会被这些没必要重传的分组充斥
选择重传SR协议通过让发送方仅重传那些它怀疑在接收方出错（丢失或受损）的分组而避免了不必要的重传
接收方确认正确接收的分组而不管是否有需，失序的分组被缓存知道所有丢失被收到为止，这时才可以将这一批收到的分组交给上层
！！！
接收方重新确认已收到的那些序号小于当前窗口基序号的分组
假设分组send_base的ACK没有从接收方传回发送方，发送方的窗口不能向前移动，发送方会一直发送send_base的分组，如果不确认的话不能继续之后的传送
有限序号范围的现实时，发送方和接收方窗口间缺乏同步会产生严重的后果
例子：
有包括4个分组序号0、1、2、3的有限序号范围且窗口长度为3。假定发送了分组0至2,并在接收方被正确接收且确认了。此时,接收方窗口落在第4、5、6个分组上，其序号分别为3、0、1。现在考虑两种情况。在第一种情况下，如图所示，对前3个分组的ACK丢失，因此发送方重传这些分组。因此，接收方下一步要接收序号为0的分组，即第一个发送分组的副本
在第二种情况下，如图所示，对前3个分组的ACK都被正确交付。因此发送方向前移动窗口并发送第4、5、6个分组，其序号分别为3、0、10序号为3的分组丢失，但序号为0的分组到达（一个包含新数据的分组）。
对接收方来说，无法知道发送方的动作，此时发送方发送的是编号为 0 的分组，接收方无法判断是第 1 个分组重传还是第 5 个分组的初次传输，所以窗口长度比序号空间小 1 时协议无法工作
窗口长度必须小于或等于序号空间大小的一半
总结：
单段物理线路时一般是有序，然而在网络中，分组重新排序是可能的
表现：
序号或确认号为x的分组的旧副本可能会出现，即使发送方或者接收方的窗口都没有x，可将信道看成在缓冲分组，将来会自然而然释放，但是由于序号会被重新使用，需要小心这些冗余分组
实际采用的方法：
确保序号不被重新使用，直到发送方确认序号为x的分组不在网络中，通过设定分组在网络存活的时间，TCP中设置 3 分钟，超过则认为分组失效
原文：https://www.cnblogs.com/zephxu/p/14749429.html