新疆人被限制出境:TCP\UDP

TCP(Transmission Control Protocol )

      （RFC-793） 
      一种面向连接（连接导向）的、可靠的、基于字节流的运输层（Transport layer）通信协议。

      应用层向TCP层发送8位字节表示的数据流，TCP把数据流分割成适当长度的报文段（通常受该数据链路层的最大传送单元(MTU)的限制）。之后, TCP把结果包传给IP层，由它来通过网络将包传送给接收端实体的TCP层。

      TCP为了保证不发生丢包，就给每个字节一个序号，同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的包发回一个相应的确认(ACK)；如果发送端实体在合理的往返时延(RTT)内未收到确认，那么对应的数据（假设丢失了）将会被重传。TCP用一个校验和函数来检验数据是否有错误，在发送和接收时都要计算校验和。 

+ Bits 0–3 4–7 8–15 16–31 0 来源连接埠(Source port) 目的连接埠(Destination port) 32 序列号码(Sequence number) 64 确认号码(Acknowledgement number) 96 标题长度(Offset) 保留(Reserved) 标志符(U A P R S F) 窗口大小(Window) 128 检查码(Checksum) 紧急指标(Urgent pointer) 160 选用(Option + Padding) 160/192+ 数据(Data)

• Source Port – 识别上层源处理器接收 TCP 服务的点。
• Destination Port – 识别上层目标处理器接收 TCP 服务的点。
• Sequence Number – 通常指定分配到当前信息中的数据首字节的序号。在连接建立阶段，该字段用于设别传输中的初始序列号。
• Acknowledgment Number – 包含数据包发送端期望接收的数据下一字节的序列号。一旦连接成功，该值会一直被发送。
• Data Offset – 4 位。TCP 协议头中的32位字序号表示数据开始位置。
• Reserved – 6位。预留以备用，必须设置为0。
• Control Bits （Flags） – 6位。传送各种控制信息。控制位可以是：

• Window – 16位。指定发送端接收窗口的大小，也就是说，数据可用的八位缓存区大小。
• Checksum – 16 位。指出协议头在传输中是否遭到破坏。
• Urgent Pointer – 16 位。指向数据包中的第一个重要数据字节。
• Option + Padding – 指定各种 TCP 选项。可选项有两种可能形式：单个八位可选类型和八位可选类型，八位可选长度和实际可选数据八位位组。
• Data – 包含上层信息。 

通路的建立和终结

      一对终端同时初始化它们之间的连接是可能的。但通常是，由一端打开一个套接字(socket)然后监听来自另一方的连接，这就是通常所指的被动打开(passive open)。服务器端被被动打开以后，用户端就能开始建立主动打开(active open)。

1. 客户端通过向服务器端发送一个SYN来建立一个主动打开，作为三路握手的一部分。
2. 服务器端应当为一个合法的SYN回送一个SYN/ACK。
3. 最后，客户端再发送一个ACK。这样就完成了三路握手，并进入了连接建立状态。 

数据传输

      可靠性机制： 1）使用序号，对收到的TCP报文段进行排序以及检测重复的数据；

                       2）使用校验和来检测报文段的错误；

                       3）使用确认和计时器来检测和纠正丢包或延时。

    1)序列号和确认

      在TCP的连接建立状态，两个主机的TCP层间要交换初始序号(ISN:initial sequencenumber)。这些序号用于标识字节流中的数据，并且还是对应用层的数据字节进行记数的整数。通常在每个TCP报文段中都有一对序号和确认号。TCP报文发送者认为自己的字节编号为序号，而认为接收者的字节编号为确认号。TCP报文的接收者为了确保可靠性，在接收到一定数量的连续字节流后才发送确认。这是对TCP的一种扩展，通常称为选择确认（Selective Acknowledgement）。选择确认使得TCP接收者可以对乱序到达的数据块进行确认。每一个字节传输过后，ISN号都会递增1。

      通过使用序号和确认号，TCP层可以把收到的报文段中的字节按正确的顺序交付给应用层。序号是32位的无符号数，在它增大到2³²-1时，便会回绕到0。对于ISN的选择是TCP中关键的一个操作，它可以确保强壮性和安全性。

    2）数据传输举例 

1. 放送方首先发送第一个包含序列号为1（可变化）和1460字节数据的TCP报文段给接收方。接收方以一个没有数据的TCP报文段来回复（只含报头），用确认号1461来表示已完全收到并请求下一个报文段。
2. 发送方然后发送第二个包含序列号为1461和1460字节数据的TCP报文段给接收方。正常情况下，接收方以一个没有数据的TCP报文段来回复，用确认号2921来表示已完全收到并请求下一个报文段。发送接收这样继续下去。
3. 然而当这些数据包都是相连的情况下，接收方没有必要每一次都回应。比如，他收到第1到5条TCP报文段，只需回应第五条就行了。在例子中第3条TCP报文段被丢失了，所以尽管他收到了第4和5条，然而他只能回应第2条。
4. 放送方在发送了第三条以后，没能收到回应，因此当时钟（timer）过时（expire）时，他重发第三条。（每次发送者发送一条TCP报文段后，都会重启动一次时钟:RTT）。
5. 这次第三条被成功接收，接收方可以直接确认第5条，因为4，5两条已收到。

TCP数据传输

校验和

      发送者将TCP报文段的头部和数据部分的和计算出来，再对其求反码(一的补数)，就得到了校验和，然后将结果装入报文中传输。（这里用反码和的原因是这种方法的循环进位使校验和可以在16位、32位、64位等情况下的计算结果在叠加后相同）接收者在收到报文后再按相同的算法计算一次校验和。这里使用的反码使得接收者不用再将校验和字段保存起来后清零，而可以直接将报文段连同校验加总。如果计算结果是全部为一，那么就表示了报文的完整性和正确性。

      注意：TCP校验和也包括了96位的伪头部，其中有源地址、目的地址、协议以及TCP的长度。这可以避免报文被错误地路由。

      按现在的标准，TCP的校验和是一个比较脆弱的校验。具有高出错率的数据链路层需要额外的连接错误纠正和探测能力。如果TCP是在今天被设计，它很可能有一个32位的CRC校验来纠错，而不是使用校验和。但是通过在第二层使用通常的CRC或更完全一点的校验可以部分地弥补这种脆弱的校验。第二层是在 TCP层和IP层之下的，比如PPP或以太网，它们使用了这些校验。但是这也并不意味着TCP的16位校验和是冗余的，对于因特网传输的观察，表明在受CRC保护的各跳之间，软件和硬件的错误通常也会在报文中引入错误，而端到端的TCP校验能够捕捉到很多的这种错误。这就是应用中的端到端原则。

流量控制和阻塞管理

      数据发送者之间用对接收数据的确认或不予确认来显式的表示TCP发送者和接收者之间的网络状态。再加上计时器，TCP发送者和接收者就可以改变数据的流动情况。这就是通常所指的流量控制（Flow control），拥塞控制/或拥塞避免。TCP使用大量的机制来同时获得强壮性和高可靠性。这些机制包括：滑动窗口、慢启动算法、拥塞避免算法、快速重启和快速恢复算法等等。对于TCP的可靠的丢包处理、错误最小化、拥塞管理以及高速运行环境等机制的优化的研究和标准制定，正在进行之中。若有丢失封包，则从丢失的封包开始重送。UDP因为得确认正确了才能传送下一阶段，因此没有办法作流量管制。

TCP的端口：标识发送方和接收方的应用层

      对每个TCP连接的一端都有一个相关的16位元的无符号端口号分配给它们。端口被分为三类：众所周知的、注册的和动态/私有的。众所周知的端口号是由因特网赋号管理局(IANA)来分配的，并且通常被用于系统一级或根进程。众所周知的应用程序作为服务器程序来运行，并被动地侦听经常使用这些端口的连接。例如：FTP、TELNET、SMTP、HTTP等。注册的端口号通常被用来作为终端用户连接服务器时短暂地使用的源端口号，但它们也可以用来标识已被第三方注册了的、被命名的服务。动态/私有的端口号在任何特定的TCP连接外不具有任何意义。可能的、被正式承认的端口号有65535个。

TCP数据传输不同于UDP之处

• 有序数据传输
• 重发丢失的封包
• 舍弃重复的封包
• 无错误数据传输
• 阻塞/流量控制
• 连接导向（确认有建立三方交握，连线已建立才作传输。）

通路的终结

连接终止状态使用了四路握手过程，在这个过程中每个终端的连接都能独立地被终止。因此，一个典型的拆接过程需要每个终端都提供一对FIN和ACK。 

注意

TCP并不是对所有的应用都适合，一些新的带有一些内在的脆弱性的运输层协议也被设计出来。比如，实时应用并不需要甚至无法忍受TCP的可靠传输机制。在这种类型的应用中，通常允许一些丢包、出错或拥塞，而不是去校正它们。例如通常不使用TCP的应用有：实时流多媒体（如因特网广播）、实时多媒体播放器和游戏、IP电话（VoIP）等等。任何不是很需要可靠性或者是想将功能减到最少的应用可以避免使用TCP。在很多情况下，当只需要多路复用应用服务时，用户数据报协议（UDP）可以代替TCP为应用提供服务。

UDP（User Datagram Protocol）用户数据报协议

      RFC 768） 
      UDP是和TCP协议处于传输层协议层中，但是与TCP协议不同，UDP协议并不提供超时重传，出错重传等功能，也就是说其是不可靠的协议。

UDP协议头
UDP端口号
      由于很多软件需要用到UDP协议，所以UDP协议必须通过某个标志用以区分不同的程序所需要的数据包。端口号的功能就在于此，例如某一个UDP程序A在系统中注册了3000端口，那么，以后从外面传进来的目的端口号为3000的UDP包都会交给该程序。端口号理论上可以有2^16这么多。因为它的长度是16个bit。

UDP检验和
      这是一个可选的选项，并不是所有的系统都对UDP数据包加以检验和数据(相对TCP协议的必须来说)，但是RFC中标准要求，发送端应该计算检验和。

      UDP检验和覆盖UDP协议头和数据，这和IP的检验和是不同的，IP协议的检验和只是覆盖IP数据头，并不覆盖所有的数据。UDP和TCP都包含一个伪首部，这是为了计算检验和而摄制的。伪首部甚至还包含IP地址这样的IP协议里面都有的信息，目的是让UDP两次检查数据是否已经正确到达目的地。如果发送端没有打开检验和选项，而接收端计算检验和有差错，那么UDP数据将会被悄悄的丢掉（不保证送达），而不产生任何差错报文。

UDP长度
      UDP可以很长很长，可以有65535字节那么长。但是一般网络在传送的时候，一次一般传送不了那么长的协议（涉及到MTU的问题），就只好对数据分片，当然，这些是对UDP等上级协议透明的，UDP不需要关心IP协议层对数据如何分片，下一个章节将会稍微讨论一些分片的策略。

IP分片
      IP在从上层接到数据以后，要根据IP地址来判断从那个接口发送数据（通过选路），并进行MTU的查询，如果数据大小超过MTU就进行数据分片。数据的分片是对上层和下层透明，而数据也只是到达目的地还会被重新组装，不过不用担心，IP层提供了足够的信息进行数据的再组装。

      在IP头里面，16bit识别号唯一记录了一个IP包的ID,具有同一个ID的IP片将会被重新组装；而13位片偏移则记录了某IP片相对整个包的位置；而这两个表示中间的3bit标志则标示着该分片后面是否还有新的分片。这三个标示就组成了IP分片的所有信息，接受方就可以利用这些信息对IP数据进行重新组织（就算是后面的分片比前面的分片先到，这些信息也是足够了）。

      因为分片技术在网络上被经常的使用，所以伪造IP分片包进行流氓攻击的软件和人也就层出不穷。可以用Trancdroute程序来进行简单的MTU侦测。

UDP和ARP之间的交互式用
      这是不常被人注意到的一个细节，这是针对一些系统地实现来说的。当ARP缓存还是空的时候。UDP在被发送之前一定要发送一个ARP请求来获得目的主机的MAC地址，如果这个UDP的数据包足够大，大到IP层一定要对其进行分片的时候，想象中，该UDP数据包的第一个分片会发出一个ARP查询请求，所有的分片都辉等到这个查询完成以后再发送。事实上是这样吗？

      结果是，某些系统会让每一个分片都发送一个ARP查询，所有的分片都在等待，但是接受到第一个回应的时候，主机却只发送了最后一个数据片而抛弃了其他，这实在是让人匪夷所思。这样，因为分片的数据不能被及时组装，接受主机将会在一段时间内将永远无法组装的IP数据包抛弃，并且发送组装超时的ICMP报文（其实很多系统不产生这个差错），以保证接受主机自己的接收端缓存不被那些永远得不到组装的分片充满。

ICMP源站抑制差错
      当目标主机的处理速度赶不上数据接收的速度，因为接受主机的IP层缓存会被占满，所以主机就会发出一个“我受不了”的一个ICMP报文。

UDP服务器设计
      UDP协议的某些特性将会影响我们的服务器程序设计，大致总结如下：

      关于客户IP和地址：服务器必须有根据客户IP地址和端口号判断数据包是否合法的能力（这似乎要求每一个服务器都要具备） 
      关于目的地址：服务器必须要有过滤广播地址的能力。 
      关于数据输入：通常服务器系统的每一个端口号都会和一块输入缓冲区对应，进来的输入根据先来后到的原则等待服务器的处理，所以难免会出现缓冲区溢出的问题，这种情况下，UDP数据包可能会被丢弃，而应用服务器程序本身并不知道这个问题。 
      服务器应该限制本地IP地址，就是说它应该可以把自己绑定到某一个网络接口的某一个端口上。