TCP与UDP 数据报文

TCP

我们如何区分一台电脑上的不同应用进程？就像我们区分人一样，不同的人给标识不同的名字，偶尔还会遇到重名的，在计算机上重名的现象就禁止发生的，不同的应用进程，区分它们的是不同的端口号，有人占了这个端口运行，就不允许别人使用这个端口，所以不管是UDP协议还是TCP协议中端口号都尤为重要，源端口和目的端口都必不可少的，没有他们计算机不知道把数据发给哪个应用进程。

源端口：源头，发送方计算机上的端口号。

目的端口：接收一方计算机的端口号。

序号：序号，顾名思义，序号就是编号，给每个传输的字节编个号。老大，老二，老三，这样TCP就知道了，哪个应该先来，哪个应该后到，就解决了乱序的问题，在写的第一篇随笔中，用抓包工具给大家展示的三次握手，如果大家有注意可以看到sequence Number总是为0，其实不是这样的，seq的增加是和传输的字节数相关的，抓包工具为了显示更友好，使用相对序号。

确认号：这个就更好理解了，我给你写封信（发包），发出去总要有回信吧，确认一下信收到没，如果没回，我就认为信可能某种原因，丢了（包）。那我就继续发，直到你收到为止。这就解决丢包的问题，所以我们认为TCP是靠谱协议，但对于TCP来说，他面临的网络环境是很复杂的，如果网络状况确实很差，是没有任何有效的保证的，TCP也无能为力，唯一能做的，就是努力的重传。

数据偏移：数据偏移还有个名称也叫首部长度，因为TCP首部是长度可变的，这个报文段到底多长，也就是说指出TCP数据部分在整个TCP报文段的什么位置。

接下来就是一些状态位了，在第一篇随笔中有提过，SYN发起联机，ACK回复，RST重新联机，FIN结束联机等，前文提过TCP协议是双工的，双方要维护连接的状态，这些带状态位包的发送，会引起双方状态的变化。就像现实中，人与人之间，双方不断发出不同信号，两边的关系也会不断变化，个人认为是一个道理的。

窗口：说得专业点，告知发送端这个接收端缓存有多少，控制发送端发送数据的速率，达到流量控制。其实就是通信双方都声明一个窗口，标识出自己能够处理的能力，别丫的发送太快，把接收端撑爆，也别发得太慢，浪费了处理能力。

检验和：这个就有点像我们常见的验证码了，主要是对整个TCP报文段来说，TCP首部和数据在发送端和接收端之间发生任何的改动，接收方检验有差错，这个TCP段就会被直接丢弃。

紧急指针:紧急指针，就要想起我们的标志位UGR,它要配合URG一起使用，意思就是这个紧急指针只有在URG被置位才有用。紧急，紧急，八百里加急，它的作用很明显，TCP知道你要发送紧急数据，TCP会将接下来数据发送中，所有TCP报文段URG标志置位，哪怕你报文段没有紧急数据，这个动作要持续到紧急数据被发送为止。要注意的是紧急数据并不会开辟一条新的连接通道单独发送，依然是随着普通数据一起发送。

选项部分：最长报文大小，接收方或发送方所能接受的最大报文段的长度。通常连接方都在通信的第一个报文段中指明这个选项。

填充：见名知义，选项部分如果不是32位的整数倍，要添加填充位，加入额外的零，保证TCP头是32的整数倍。

数据部分： TCP 报文段中的数据部分是可选的。在一个连接建立和一个连接终止时，双方交换的报文段仅有 TCP 首部。如果一方没有数据要发送，也使用没有任何数据的首部来确认收到的数据。在处理超时的许多情况中，也会发送不带任何数据的报文段。

UDP

一、UDP的概述（User Datagram Protocol，用户数据报协议）
UDP是传输层的协议，功能即为在IP的数据报服务之上增加了最基本的服务：复用和分用以及差错检测。

UDP提供不可靠服务，具有TCP所没有的优势：

• UDP无连接，时间上不存在建立连接需要的时延。空间上，TCP需要在端系统中维护连接状态，需要一定的开销。此连接装入包括接收和发送缓存，拥塞控制参数和序号与确认号的参数。UCP不维护连接状态，也不跟踪这些参数，开销小。空间和时间上都具有优势。
  举个例子：DNS如果运行在TCP之上而不是UDP，那么DNS的速度将会慢很多。
  HTTP使用TCP而不是UDP，是因为对于基于文本数据的Web网页来说，可靠性很重要。
  同一种专用应用服务器在支持UDP时，一定能支持更多的活动客户机。
• 分组首部开销小**，TCP首部20字节，UDP首部8字节。
• UDP没有拥塞控制，应用层能够更好的控制要发送的数据和发送时间，网络中的拥塞控制也不会影响主机的发送速率。某些实时应用要求以稳定的速度发送，能容 忍一些数据的丢失，但是不能允许有较大的时延（比如实时视频，直播等）
• UDP提供尽最大努力的交付，不保证可靠交付。所有维护传输可靠性的工作需要用户在应用层来完成。没有TCP的确认机制、重传机制。如果因为网络原因没有传送到对端，UDP也不会给应用层返回错误信息
• UDP是面向报文的，对应用层交下来的报文，添加首部后直接乡下交付为IP层，既不合并，也不拆分，保留这些报文的边界。对IP层交上来UDP用户数据报，在去除首部后就原封不动地交付给上层应用进程，报文不可分割，是UDP数据报处理的最小单位。
  正是因为这样，UDP显得不够灵活，不能控制读写数据的次数和数量。比如我们要发送100个字节的报文，我们调用一次sendto函数就会发送100字节，对端也需要用recvfrom函数一次性接收100字节，不能使用循环每次获取10个字节，获取十次这样的做法。
• UDP常用一次性传输比较少量数据的网络应用，如DNS,SNMP等，因为对于这些应用，若是采用TCP，为连接的创建，维护和拆除带来不小的开销。UDP也常用于多媒体应用（如IP电话，实时视频会议，流媒体等）数据的可靠传输对他们而言并不重要，TCP的拥塞控制会使他们有较大的延迟，也是不可容忍的

二、UDP的首部格式

UDP数据报分为首部和用户数据部分，整个UDP数据报作为IP数据报的数据部分封装在IP数据报中，UDP数据报文结构如图所示：

UDP首部有8个字节，由4个字段构成，每个字段都是两个字节，
1.源端口： 源端口号，需要对方回信时选用，不需要时全部置0.
2.目的端口：目的端口号，在终点交付报文的时候需要用到。
3.长度：UDP的数据报的长度（包括首部和数据）其最小值为8（只有首部）
4.校验和：检测UDP数据报在传输中是否有错，有错则丢弃。
该字段是可选的，当源主机不想计算校验和，则直接令该字段全为0.
当传输层从IP层收到UDP数据报时，就根据首部中的目的端口，把UDP数据报通过相应的端口，上交给应用进程。
如果接收方UDP发现收到的报文中的目的端口号不正确（不存在对应端口号的应用进程0,），就丢弃该报文，并由ICMP发送“端口不可达”差错报文给对方。