10、11章：UDP和TCP - 用TCP/IP进行网际互连

第11章 用户数据包协议(UDP)

        为了能够与外部端口通信，发送方不仅需要知道目的机器的IP地址，还需要知道该机器内目的地的协议端口号。每个报文必须携带送达机器的目的端口(destination port)号，还必须携带回答报文应反送至源机器的源端口(source port)号。这样，任何接收到报文的进程才能回答发送方。

       大多数操作系统提供了同步的端口访问。如果一个进程试图在任何数据到达之前从端口提取数据，则操作系统会暂时停止（阻塞）进程，知道数据到达。一旦数据到达，操作系统把数据传递给这个进程并重新启动它。通常端口带缓冲。

 

11.3 用户数据报协议

        UDP使用下层的互联网层把报文从一台机器传输到另一台机器，与IP一样，提供的也是不可考、无连接的数据报文交付语义。它没有使用确认来确保报文到达，没有对收到的报文排序，也不提供反馈信息来控制机器之间信息流动的数度。因此，UDP报文可能会出现丢失、重复或无序到达的现象。

        总之：UDP使用IP在机器之间传输报文，提供的是不可靠、无连接的交付服务。它使用IP来运载报文，但比IP增加了区分指定主机上的多个目的地址的能力。

 

11.3 UDP报文格式

源端口(sourceport)和目的端口(destination port)字段包含了一个16位的UDP协议端口号，用来在各个等待接收数据报的进程之间对数据报进行分用。源端口字段是可选的，若不选用此字段应为0

长度字段(length)字段指明了该数据报中八位组的个数，包括UDP首部和数据的长度，因此，长度字段至少为8，即首部长度。

UDP检验和(checksum)讲解见11.5 UDP伪首部

 

11.5 UDP伪首部

       UDP检验和计算涉及的范围超出了UDP 数据报本身。为了计算检验和，UDP 把伪首部（pseudo-header）引入数据报中，并且为了保证数据报长度为16比特整数倍，还添加了一个全零八位组来填充数据报，最后为整个对象计算检验和。用于填充数据报的八位组和伪首部并不随UDP数据报一起传输，也不计算在数据报长度之内。为了计算检验和，软件先在检验和（CHECKSUM）字段中存储零值，然后对整个对象，包括伪首部、UDP的首部和用户数据，计算16位的二进制反码和。

       使用伪首部的目的是验证UDP数据报是否已到达正确的终点。理解伪首部的关键在于认识到：一个正确的终点包括一台特定的主机和该机器上的一个特定协议端口。UDP 首部本身仅仅指明了协议端口号。因此，为了验证终点正确与否，发送端机器上的UDP 在计算检验和时把目的机器的IP地址和UDP数据报都包括在内(UDP数据报包括首部和数据)。在最终的目的机器上，UDP协议软件对检验和进行验证时，用到了携带UDP报文的IP数据报首部中的IP地址。如果检验和一致，则说明UDP数据报到达了正确主机上的正确协议端口。

11.6 UDP的封装与协议的分层

 

11.8 UDP的复用、分用和端口

        UDP端口可以把它想象成一个队列，在大多数实现中，当以指定某个端口时，操作系统就创建一个内部队列来接受报文，当UDP接受报文时，先检查报文的目的是否和使用的端口一致，否则发送一个ICMP端口不可达(port unreachable)报文并丢弃这个数据报；若匹配则把数据报送到队列中，等待应用程序访问。当然，队列满是，UDP也会丢弃该传入的数据报。

 

11.9 保留和可用的UDP端口号

11.10 小结

        UDP并没有给IP层的语义增加多少内容，在这个意义上它是一个“廋”协议。它只给应用程序提供了通信能力，使用的是IP的不可靠、无连接分组交付服务。因此，UDP的报文可能会出现丢失、重复、延迟或无序交付；使用UDP的应用程序必须负责处理这些问题。

        在协议分层方案中，UDP处于运输层，位于互联网协议层之上、应用层之下。从概念上讲，运输层和互联网层是独立的，但实际上两层有密切的联系。UDP检验和包括IP原地址和目的地址，这意味着UDP必须和IP层交互，在传输数据报之前获得这些数据。

 

第12章 可靠地流运输服务(TCP)

       IP协议的主要目标是：向IP层以上的部分隔离下层物理网络，将下层各种不同的物理网络进行互联。从而使IP层以上的所有部分与网络硬件隔离开来。总的来说，IP的作用是互联各种物理网络，对上层协议隔离底层物理网络。IP用不可靠的无连接分组交换完成了该目标。

       但是IP协议提供的是不可靠的服务，IP分组可能丢失、乱序、重复交付、延时交付，我们高层的应用程序不可能来处理这些问题。所以在IP协议层之上，我们必须提供给上层应用程序一种可靠地服务——TCP协议！

 

12.3 可靠交付服务特征

       (1)、面向流(Stream Orientation)

       (2)、虚电路连接(Virtual Circuit Connection)

       (3)、带缓冲传送(Buffered Transfer)

       (4)、无结构的流(Unstructured Stream)

       (5)、全双工连接(Full Duplex Connection)

12.4 提供可靠性

       带重传的正面确认（positive acknowledgementwith retransmission），最简单的理解是：接收方收到数据之后向源站发回一个确认（acknowledgement,简称ACK）报文。发送方在发送下一个分组之前等待该ACK确认信息。发送方还在发送分组时启动一个计时器，如果计时器超时而ACK确认没有收到，那么就重传刚才的分组。

 

12.5 滑动窗口概念

       滑动窗口协议能够让网络中得分组完全饱和，因此能够获得比简单的正面确认协议高得多的吞吐率。滑动窗口解决了端到端的流量控制（flow control）问题。注意这里是端到端的流量控制：

        TCP允许窗口大小随时改变，在每个ACK确认中，除了指明收到多少字节之外，还包括了一个窗口通告（windowadvertisment）,指出接收方准备再接受多少字节的数据。

 

12.7 端口、连接和端点

        TCP是建立在连接抽象（connection abstraction）上的

        TCP使用连接而不是协议端口作为它的基本抽象的，连接在建立时是用一对端点来标识的。也就是说，TCP连接在建立时，是根据ip和port对来建立的。在该连接建立完成之后，并不会占着该端口。也就是说，还可以用该端口来建立新的连接。

常见的例子：一个服务器在某个端口 port1 上提供基于TCP服务的服务端程序，其它客户端与该服务程序建立连接，从而来取得它的某种服务。A客户端与port1建立连接之后，并不会妨碍B客户端与port1建立连接！

       端口号：

       一个IP地址的主机可以提供多种服务，如web、FTP等，这个完全可以通过一个IP地址实现，主机怎样区分不同的网络服务？IP地址与网络服务是一对多的关系，通过“IP + 端口号”实现。

TCP报文段首部（20个字节）

1、  源端口和目标端口：

a)        各占2个字节，16比特的端标语加上32比特的IP地址，共同构成相当于传输层办事接见点的地址，即“插口”；这些端口可用来将若干高层和谈向下复用；

2、序号字段和确认序号字段：

序号：占4个字节，是本报文段所发送的数据项目组第一个字节的序号。在TCP传送的数据流中，每一个字节都有一个序号。例如，一报文段的序号为300，而起数据供100字节，则下一个报文段的序号就是400；

确认序号：占4字节，是期望收到对方下次发送的数据的第一个字节的序号，也就是期望收到的下一个报文段的首部中的序号；

因为序号字段有32比特长，可以对4GB的数据进行编号，如许就可包管当序号反复应用时，旧序号的数据早已在收集中消散了；

3、数据偏移字段

数据偏移：占4比特，默示数据开端的处所离TCP报文段的肇端处有多远。这实际上就是TCP报文段首部的长度。因为首部长度不固定，是以数据偏移字段是须要的。

4、保存字段：

6比特，供往后应用，今朝置为0。

5、6个比特的保留字段

        紧急比特URGent：当URG=1时，注解此报文应尽快传送，而不要按本来的列队次序来传送。与“紧急指针”字段共同应用，紧急指针指出在本报文段中的紧急数据的最后一个字节的序号，使接管方可以知道紧急数据共有多长；

        确认比特ACK：只有当ACK=1时，确认序号字段才有意义；

        急迫比特PSH：当PSH=1时，注解恳求远地TCP将本报文段立即传送给其应用层，而不要比及全部缓存都填满了之后再向上交付。

        复位比特ReSeT：当RST=1时，注解呈现严重错误，必须开释连接，然后再重建传输连接。复位比特还用来拒绝一个不法的报文段或拒绝打开一个连接；

        同步比特SYN：在建树连接时应用，当SYN=1而ACK=0时，注解这是一个连接恳求报文段。对方若赞成建树连接，在发还的报文段中使SYN=1和ACK=1。是以，SYN=1默示这是一个连接恳求或毗邻接管报文，而ACK的值用来区分是哪一种报文；

         终止比特FINal：用来开释一个连接，当FIN=1时，注解欲发送的字节串已经发完，并请求开释传输连接；

7、窗口字段

        窗口Window：占2字节，默示报文段发送方的接管窗口，单位为字节。此窗口告诉对方，“在未收到我的确认时，你可以或许发送的数据的字节数至多是此窗口的大小。”

        通知窗口advertised window：接管端按照其接管才能承诺的窗口值，是来自接管端的流量把握。接管端将通知窗口的值放在TCP报文的首部中，传送给对方。

        拥塞窗口congestion window：是发送端按照收集拥塞景象得出的窗口值，是来自发送端的流量把握。

8、检验和

        查验和覆盖了全部的TCP报文段：TCP首部和TCP数据。这是一个强迫性的字段，由发端策画和存储，由收端进行验证。

9、紧急指针

        当URG为置1时，紧急指针指明了紧急数据的末尾在数据报中的位置。

 

12.24 建立一个TCP连接

TCP用三次握手建立一个连接

        通过设置代码字段的SYN位为1可以识别出握手的第一个报文段，第二段报文把SYN和ACK位均置1，表示这是对第一个SYN报文段的确认，并继续握手操作。最后一个握手仅仅是一个确认信息，通知目的主机双方都同意：已建立这个连接。

 

12.25 初始序号

       每个报文段包含序号字段和确认字段，发起握手的机器A把自己的初始序号x放到三次握手协议的第一个SYN报文段中，传到机器B。机器B收到SYN后，记下这个序号，再把自己的初始序号y放到序号字段中，同时在确认字段中表明B等待接收第x+1号八位组，然后把这个报文段发给A。在最后一个握手报文段中，A知道了要从第y号八位组起接收B的流。在各种情况下，确认都约定使用期望收到的下一个八位组的编号。

 

12.26 TCP关闭一个连接操作

TCP协议的连接是全双工连接，一个TCP连接存在双向的读写通道。

简单说来是 “先关读，后关写”，一共需要四个阶段。以客户机发起关闭连接为例：

1.服务器读通道关闭

2.客户机写通道关闭

3.客户机读通道关闭

4.服务器写通道关闭

       关闭行为是在发起方数据发送完毕之后，给对方发出一个FIN（finish）数据段。直到接收到对方发送的FIN，且对方收到了接收确认ACK之后，双方的数据通信完全结束，过程中每次接收都需要返回确认数据段ACK。

详细过程：

     第一阶段   客户机发送完数据之后，向服务器发送一个FIN数据段，序列号为i；

          1.服务器收到FIN(i)后，返回确认段ACK，序列号为i+1，关闭服务器读通道；

          2.客户机收到ACK(i+1)后，关闭客户机写通道；

         （此时，客户机仍能通过读通道读取服务器的数据，服务器仍能通过写通道写数据）

    第二阶段 服务器发送完数据之后，向客户机发送一个FIN数据段，序列号为j；

          3.客户机收到FIN(j)后，返回确认段ACK，序列号为j+1，关闭客户机读通道；

          4.服务器收到ACK(j+1)后，关闭服务器写通道。

    这是标准的TCP关闭两个阶段，服务器和客户机都可以发起关闭，完全对称。

    FIN标识是通过发送最后一块数据时设置的，标准的例子中，服务器还在发送数据，所以要等到发送完的时候，设置FIN（此时可称为TCP连接处于半关闭状态，因为数据仍可从被动关闭一方向主动关闭方传送）。如果在服务器收到FIN(i)时，已经没有数据需要发送，可以在返回ACK(i+1)的时候就设置FIN(j)标识，这样就相当于可以合并第二步和第三步。

 

12.28 TCP状态机

12.30 保留的TCP端口号

12.34 小结

       传输控制协议(TCP)定义了由互联网提供的一个关键服务，即可靠的流交付。TCP提供两台机器之间的全双工交互，允许高效传输数据。

       TCP使用滑动窗口协议来高效使用网络，由于TCP几乎不给下层交付提要求，能够灵活的在各交付系统上运行。由于TCP提供流量控制，能够在各种速率网络中使用。

       TCP通过让接收方通告其愿意接受的数据量来实现流量控制，还是用紧急指针和推操作来支持带外报文的传输。

如何计算UDP/TCP检验和checksum

一、下面的图是一个UDP的检验和所需要用到的所有信息，包括三个部分：

1.UDP伪首部

2.UDP首部

3.UDP的数据部分（切记不要遗漏该部分，否则就~吐血了~）

首先解释下伪首部的概念，伪首部包含IP首部一些字段。其目的是让UDP两次检查数据是否已经正确到达目的地，只是单纯为了做校验用的。

还有一个概念十分重要，那就是16位UDP总长度，请注意该长度不是报文的总长度，而只是UDP（包括UDP头和数据部分）的总长度（之前就是因为这个概念没弄清楚，走了不少弯路，吐血~~）。

 

二、计算检验和（checksum）的过程很关键，主要分为以下几个步骤：

1.把伪首部添加到UDP上；

2.计算初始时是需要将检验和字段添零的；

3.把所有位划分为16位（2字节）的字

4.把所有16位的字相加，如果遇到进位，则将高于16字节的进位部分的值加到最低位上，举例，0xBB5E+0xFCED=0x1 B84B，则将1放到最低位，得到结果是0xB84C

5.将所有字相加得到的结果应该为一个16位的数，将该数取反则可以得到检验和checksum。

 

三、事实胜于雄辩，还是举个例子来分析一下吧，该例子计算的是一个TCP的检验和（和UDP的算法一致）

TCP计算检验和的报文结构如下所示：

抓包工具抓了一个TCP 的syn报文做研究，呵呵，下面就是整个报文：

1.首先将检验和部分添零；

2.然后将TCP伪首部部分，TCP首部部分，数据部分都划分成16位的一个个16进制数；

3.将这些数逐个相加，记得溢出的部分加到最低位上，这是循环加法：

 0xc0a8+ 0x0166+……+0x0402=0x9b49

4.最后将得到的结果取反，则可以得到检验和位0x64B6

 

按照上述步骤进行计算就可以得到检验和为0x64B6，大家也可以试试看

IP数据报只检验IP数据报的首部，但UDP检验的是把首部和数据部分一起都检验。

参考资料：

1、《用TCP/IP进行网际互联 卷一 第五版》第11章和第12章

2、(网上资料) TCP报文格式详解

3、(网上资料) 如何计算UDP/TCP检验和checksum