TCP/UDP

UDP 用户数据报协议

1、UDP 是无连接的，即在发送数据之前不需要先建立连接（当然，发送数据之后 也没有连接可以释放），也就是从应用层接收到的报文，添加上自己的首部之后，直接发送，不需要 优先发送连接报文。
2、UDP 尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的连接状态表（这里面有许多参数）
3、UDP 是面向报文的。发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付IP层。UDP对应用层交下来的报文即不合并也不拆分，而是保留这些报文的边界。这就是说应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文。在接收方UDP，对IP层交上来的用户数据报，在去除首部后就原封不动的交付应用层进程。也就是说UDP一次交付一个完整的报文。因此应用程序必须选择合适大小的报文。若报文太长，UDP把它交给IP层后，IP层在传送时可能要进行分片，这会降低IP层的效率。反之，若报文太短，UDP把它交给IP层后，会使IP数据报的首部的相对长度太大，也会降低IP层的效率。

图一
4、UDP没有拥塞控制。因此网络出现的拥塞不会使源主机的发送速率降低，这对某些实时应用是很重要的。很多实时应用（如IP电话，实时视频会议）要求源主机以恒定的速率发送数据，并且运行在网络发生拥塞时丢弃一些数据（如卡顿），但却不允许数据有太大的时延。UDP正好适合这种要求。
5、UDP支持一对一，一对多，多对多，多对一的交互通信
6、UDP首部开销小，只有8个字节，比TCP20个字节的首部要短。
虽然某些实时应用需要使用没有拥塞控制的UDP，担当很多源主机同时向网络发送高速率的实时视频流时，网络就有可能发生拥塞，结果大家都可能无法正常接收。因此不使用拥塞控制功能的UDP有可能会引起网络产生严重的拥塞问题。
还有一些使用UDP的实时应用，需要对UDP的不可靠的传输景行适当的改进，以减少数据的丢失。在这种情况下，应用进程本身可以在不影响应用的实时性的前提下，增加一些提高可靠性的措施，如采用 向前纠错或重传已丢失的报文。

UDP应用场景

• 包总量较小的通信（DNS、SNMP）
• 视频音频等实时通信
• 广播通信

UDP 报文结构

用户数据报UDP有两个字段：数据字段和首部字段。首部字段只有8个字节，而且首部由4个字段组成，每个字段占两个字节。各字段意义如下：

• 源端口
  源端口号。在需要对方回信时选用，不需要时可用全0
• 目的端口号
  这在终点交付报文时必须使用
• 长度
  UDP用户数据报的长度，其最小值是8（仅有首部）
• 检验和
  检测UDP用户数据报在传输中是否有错。有错就丢弃

UDP数据报

伪首部的第3字段是全0，第4字段是IP首部中的协议字段值。对于UDP，此协议字段值为17，第5字段是UDP用户数据报的长度。

当运输层从IP层收到UDP数据报时，就根据首部中的目的断开，把UDP数据报通过响应的断开，上交最后的终点：应用进程，如图：

UDP分用
如果接收方UDP发现收到的报文中的目的端口号不正确（即不存在端口号队对应的应用进程），就丢弃该报文，并由于网际控制报协议ICMP发送“端口不可达”差错报文给发送方。
请注意：虽然在UDP之间的通信要用到其端口号，但由于UDP的通信是无连接的，因此不需要使用套接字（ip地址：端口号）来建立连接(TCP 之间的通信必须要在两个套接字之间建立连接)。

检验和计算

计算检验和时 要在UDP用户数据报之前增加12个字节的伪首部，所谓伪首部是因为这种伪首部并不是用户数据报的真正的首部。只在计算检验和时临时添加在UDP用户数据报前面，得到一个临时的UDP用户数据报。检验和就是按照这个临时的UDP用户数据报来计算的。伪首部既不向下传送又不向上提交，而仅仅是为了计算检验和。
在发送方，首先是把全零放入检验和字段。再把伪首部以及UDP用户数据报看成是由许多16位的字串接起来的，若UDP用户数据报的数据部分不是偶数个字节，则要填入一个全零的字节（但此字节不发送），然后按二进制反码计算出这些16位字的和。将此和的二进制 反码 写入检验和字段后，就发送这样的UDP用户数据报。
在接收方，把收到的用户数据报连同伪首部（以及可能的填充全零字节）一起，按二进制反码求这些16位字的和。当无差错时 其结果为1，否则就表明有差错出现，接收方就应该丢弃这个UDP用户数据报，也可以上交给应用层，但附上出现了差错的警告。如下图，给出了一个UDP检验和的例子。这里假定用户数据报的长度是15字节（首部8个字节，数据7个字节），因此要添加一个全0的字节。可以自己检验一下，接收方是如何对检验和进行检验的。

检验和计算

TCP传输控制协议

TCP的主要特点

• TCP是面向连接的运输层协议。这就是说应用程序在使用TCP协议之前，必须先建立TCP连接。在传送数据完毕后必须释放已经建立的TCP连接。
• 每一条TCP连接只能有两个端点，每个TCP连接只能是点对点的（一对一）
• TCP提供可靠交付的服务，通过TCP连接传输的数据，无差错，不丢失，不重复，并且按序到达。
• TCP提供全双工通信。TCP允许通信双方的应用进程在任何时候都能发送数据。TCP连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信的数据。在发送时，应用程序在把数据传送给TCP的缓存后，就可以做自己的事，而TCP在合适的时候把缓存的数据发送出去。在接收时TCP把接收的数据放入缓存，上层的应用进程在合适的时候读取缓存数据。
• 面向字节流。TCP中的流，指的是流入到进程或从进程流出的字节序列。“面向字节流”的含义是，虽然应用程序和TCP的交互是一次一个数据块（大小不等），但TCP把应用程序交下拉的数据仅仅看成是一连串的无结构的字节流。TCP并不知道所传送的字节流的含义。TCP不保证接收方应用程序收到的数据块和发送方应用程序发出的数据块有对应的大小关系（例如，发送方应用程序交给发送方的TCP共10个数据块，但接收方TCP可能只用了4个数据块就把收到的字节流交付上层的应用程序）。但接收方应用程序收到的字节流必须和发送方应用程序发送的字节流完全一样。当然接收方应用程序必须有能力识别收到的字节流，把它还原成有意义的应用层数据。

TCP的连接

每一条TCP连接有两个端点。那么TCP连接的端点是什么呢、？TCP连接的端点叫 套接字（socket） 或者 插口，端口号拼接到IP地址就构成了套接字。套接字的表示方法是在点分十进制的IP地址后面拼接上端口号，中间用冒号或逗号隔开。若IP地址是 192.3.4.5 端口号是 80，那么套接字就是 192.3.4.5：80
套接字 socket = IP地址：端口号
每一条TCP连接都唯一的被通信两端的 两个端点（两个套接字）所确定。

TCP 报文段的首部格式

TCP虽然是面向字节流的，但TCP传送的数据单元确是报文段。TCP的报文段分为首部和数据两部分。而TCP的全部功能提现在他的首部各个字段中。只有弄清TCP首部各字段的作用才能了解清楚TCP的工作原理。
TCP报文段的首部前20个字节是固定的，后面4n个字节是根据需要添加的选项（n是整数），因此TCP首部的最小长度为20个字节。

TCP报文段首部格式

各字段的意义如下：

• 源端口和目的端口：各占两个字节，分别写入源端口号和目的端口号，TCP的分用功能是通过端口实现的。
• 序号：占4个字节。序号范围是【0，2^32 -1】，共2^{32个序号。序号增加到2}32 -1后，下一个序号就又回到0，TCP是面向字节流的，在一个TCP连接中传送的字节流中的每一个字节都按顺序编号。整个要传送的字节流的序号必须要在连接建立时确定。首部中的序号字段值则指的是本报文段所发送的数据的第一个字节的序号。
  例如：一个报文段的序号字段值是301，而携带的数据共有100个字节。这就表明：本报文段的数据的第一个字节的序号是301，最后一个字节的序号是400。显然，下一个报文段（如果还有的话）数据序号应该从401开始，即下一个报文段的序号字段是 401。这个字段的名称叫做报文段序号。
• 确认号：占4字节。是期望收到对方下一个报文段的第一个数据字节的序号。
  例如：B正确收到了A发送过来的一个报文段，其序号字段是501，而数据长度是200字节（序号 501-700），这表明B收到了A发送的到序号为700为止的数据。因此B期望收到A的下一个数据序号是701，于是B在发送给A的确认报文段中把确认序号设置为701，注意：现在的确认序号不是501，也不是700，而是701 。
  所以 若确认序号=N，则表明：到序号N-1为止的所有数据都已经正确收到
• 数据偏移：占4位。它指出TCP报文段的数据起始处距离TCP报文段的起始处有多远。这个字段实际上是TCP报文段的首部长度。由于首部中还有长度不确定的字段选项，因此数据偏移字段是必要的。
• 保留：占6位。保留为今后使用，但是目前应置为0。
• 紧急URG：当URG= 1时，表明紧急指针指端有效。他告诉系统此报文段中有紧急数据，应尽快传送。相当于高优先级的数据。而不要安原来的排队顺序来传送。于是发送方TCP就把紧急数据插入到本报文段数据的最前面，而在紧急数据后面的数据仍然是普通数据。
• 确认ACK：仅当ACK=1时，确认号字段才有效。当ACK=0时，确认号字段无效。TCP规定，在连接建立后所有传送的报文段都必须把ACK设置为1.
• 推送（PSH）：当两个应用的进程进行交互式的通信时，有时在一端的应用进程希望在键入一个命令后立即就能够收到对方的响应。在这种情况下TCP就使用推送操作。这时发送方TCP把PSH=1，并立即创建一个报文段发送出去。接收方TCP收到PSH=1的报文段后，就尽快的交付到应用进程，而不用等到整个缓存都填满了后再向上交付。
• 复位RST：当RST = 1时，表明TCP连接中存在严重的差错（由于主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接。RST=1还用来拒绝一个非法的报文段或拒绝打开一个连接。RST也称为重建位或者重置位。
• 同步SYN：在建立连接时用来同步序号。当SYN= 1，而ACK = 0，表明这是一个连接请求报文段。若对方同意连接，则在响应报文段中使用SYN=1，ACK=1。因此ACK=1，就表明这是一个连接请求报文或连接接受报文。
• 终止FIN：用来释放一个连接。当FIN=1，表明此报文段的发送方的数据已经全部发送完成，并要求释放运输连接。
• 窗口：占2字节。窗口指的是发送本报文段的一方的接收窗口，（而不是自己的发送窗口）。窗口值告诉对方：从本报文段首部中的确认序号算起，接收方目前允许对方发送的数据量（以字节为单位）。之所有要有这个限制，是因为接收方数据缓存空间是有限的。总之，窗口值作为接收方让发送方设置其发送窗口的依据。
  例如：发送了一个报文段，其确认号是701，窗口字段是1000，这是告诉对方：从701号算起，我（发送此报文段的一方）的接收缓存空间还可接收1000个字节数据（701-1700），你在给我发送数据时必须考虑到这一点。
• 检验和：占2字节。检验的范围包括首部和数据两部分。和UDP一样，在计算检验和时，要在TCP报文段的前面加上12个字节的伪首部，和UDP的伪首部一样。但应该把伪首部第4个字段中的17改为6，（TCP的协议号是6）。
• 选项：长度可变，最长可达40字节。当没有使用选项时，TCP的首部长度为20.

TCP的三次握手

TCP是面向连接的协议。运输连接是用来传送TCP报文的。TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程。因此运输连接有三个阶段。连接建立 数据传送 连接释放

TCP的连接建立

TCP建立连接的过程叫握手，握手需要在客户和服务器之间交换三个TCP报文段。

TCP三次握手

假定主机A运行的是TCP的客户程序，主机B运行的是TCP的服务程序。最初两端的TCP状态都处于CLOSED（关闭）状态，在图中，A主动打开链接，而B被动打开链接。
一开始，B的服务进程先创建传输控制块TCB，准备接收客户进程的连接请求。然后服务器进程就处于LISTEN（收听）状态，等待客户的连接请求。
A的TCP客户进程也是首先创建传输控制模块TCB。然后，在打算简历TCP连接时，向B发出连接请求报文段。

• A发出连接请求报文，首部中的同部位SYN=1，同时选择一个初始序号seq = x。TCP规定，SYN报文段不能携带数据，但要消耗掉一个序号，这时，TCP客户进程进入SYN-SENT（同步已发送）状态。
• B收到连接请求报文后，如果同意连接，则向A发送确认。在确认报文段中应该把SYN位和ACK位都设置为1.确认序号ack = x+1.同时也为自己选择一个初始序号seq = y。请注意，这个报文段也不能携带数据，但同样要消耗掉一个序号。这时TCP服务进程进入SYN-RCVD（同步收到）状态。
• TCP客户进程收到B的确认后，还要向B给出确认。确认报文段的ACK=1，确认序号确认号ack = y+1（期望收到B的下一个序号为y+1的报文段），而自己的序号seq = x+1；TCP的标准规定，ACK的报文段可以携带数据。但如果不携带数据则不消耗序号，在这种情况下，下一个数据报文段的序号仍是seq = x+1，这时TCP连接已经建立，A进入ESTABLISHED（已建立连接）状态。当B收到A的确认后也进入ESTABLISHED（已建立连接）状态。
  以上过程就是三次报文握手。

问题：为什么A最后还要发送一次确认？

主要是为了已失效的连接请求报文段又突然传到了B，因而产生错误。
所谓“已失效的连接请求报文段”是这样产生的：

• A发出连接请求，但因为连接请求报文丢失而未收到确认。于是A再重传一次连接请求。后来收到了确认建立了连接。数据传输完毕后就释放了连接。A共发送了两个请求报文段，其中第一个丢失，第二个到达了B，没有“已失效的连接请求报文段”。
  现假定出现一种异常情况，即A发出的第一个连接请求报文段并没有丢失，而是在某些网络节点长期滞留了，以至延误到连接释放后的某个时间才到达B。本来这是一个早已失效的报文段。但B收到这个失效的连接请求报文段后，就误认为是A发出的另一个连接请求报文段。于是就向A发出确认报文段，同意连接建立，假如不采用报文握手，那么只要B发出确认，新的连接就建立了。
  由于A并没有发出连接建立的请求，因此并没有理财B的确认，也不会向B发出数据。但B确认为新的运输连接已经建立了，并一直等待A发来数据。B的许多资源就这样白白浪费了。但是采用三报文握手的方式，以上情况下，A不会向B发出确认，B由于收不到确认，就知道A并没有要求建立连接。

TCP的连接释放（四次挥手）

TCP释放连接过程

数据传输结束后，通信的双方都可释放连接。现在A和B都处于ESTABLISHED状态，A的应用进程先向其TCP发出连接释放报文段，并停止再发送数据。主动关闭TCP连接。

• A把连接释放报文段的终止位FIN设置为1；其序号seq = u，它等于前面已传送过的数据的最后一个字节的序号+1。这时A进入FIN-WAIT-1（终止等待1）状态，等待B的确认。请注意TCP规定，FIN报文段即使不携带数据，它也消耗掉一个序号。
• B收到连接释放报文段后即发出确认，确认号是ack = u+1，而这个报文段自己的序号是seq =v，等于B前面已传送过的数据的最后一个字节的序号+1，然后B就进入CLOSE-WAIT（关闭等待状态）。TCP服务进程这时应通知高层应用进程，因而从A到B这个方向的连接就释放了，这时的TCP连接处于半关闭状态，即A已经没有数据要发送了，但B若发送数据，A仍要接收，也就是从B到A这个方向的连接没有关闭，这个状态可能会持续一段时间。
  A收到B的确认后，就进入FIN-WAIT-2（终止等待2）状态，等待B发出的连接释放报文段。
• 若B已经没有要向A发送的数据，其应用进程就通知TCP释放连接。这时B发出的连接释放报文段必须使FIN=1，现假定B的序号为w（在半关闭状态B可能又发送了一些数据）。B还必须重复上次已发送过的确认序号ack = u+1，这时B就进入了LAST-ACK（最后确认状态），等待A的确认。
• A在收到B的连接释放报文段后，必须对此发出确认，在确认报文段中把ACK=1，确认号ack = w+1，而自己的序号是 seq = u+1，（根据TCP标准，前面发送过的FIN报文段要消耗掉一个序号）。然后进入到TIME-WAIT（时间等待）状态。请注意现在TCP连接还没有释放。必须经过时间等待计时器设置的时间2MSL后，A才进入到CLOSED状态。时间MSL叫做最长报文段寿命，RFC793建议设为2分钟。但这完全是从工程上来考虑的，对于现在的网络，MSL=2分钟可能太长了一些。因此TCP允许不同的实现根据具体的情况来设置MSL值。因此，从A进入到TIME-WAIT状态后要经过4分钟才能进入到CLOSED状态，才能开始建立下一个新的连接。当A撤销相应的传输控制块TCB后，就结束了这次的TCP连接。

为什么A在TIME-WAIT 状态必须等待2MSL的时间呢？

1、为了保证A发送的最后一个ACK确认报文段能够到达B。这个ACK报文段有可能丢失，因而使处在LAST-Ack 状态的B收不到对已经发送的FIN+ACK报文段的确认。B会重传这个FIN+ACK报文段，而A就能在2MSL时间内收到这个重传的FIN+ACK报文段。接着A就重传一次确认，重新启动2MSL计时器。最后A和B就都正常进入到CLOSED状态。如果A在TIME-WAIT状态不等待一段时间，而是在发送完ACK报文段后立即释放连接，那么就无法收到B重传的FIN+ACK报文段，因而也不会再发送一次确认报文段。这样B就无法按照正常的步骤进入到CLOSED状态。
2、A在发送完最后一个ACK的报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段在网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。
B只要收到了A发出的确认，就进入到CLOSED状态，同样B在撤销相应的传输控制块TCB后，就结束了这次的TCB连接。B结束连接要比A早一些。

保活计时器

除时间等待计时器外，TCP还设有一个保活计时器。设想有这样的场景：客户已主动与服务器建立了TCP连接。后来客户端的主机突然出故障。显然服务器以后就不能在收到客户发来的数据。因此应当有措施使服务器不白白等待下去。这就是使用保活计时器。服务器每收到一次客户的数据，就重新设置保活计时器，时间的设置通常是两小时。若两小时没有收到客户的数据，服务器就发送一个探测报文段，以后每隔75秒发送一次。若一连发送10个报文段后都没有收到响应，服务器就认为客户端出了故障，就关闭这个链接。