应用层协议
只要保证, 一端发送时构造的数据, 在另一端能够正确的进行解析
HTTP1
HTTP协议格式
HTTP请求
-
首行: [方法] + [url] + [版本]
-
Header: 请求的属性, 冒号分割的键值对;每组属性之间使用\n分隔;遇到空行表示Header部分结束
-
Body: 空行后面的内容都是Body. Body允许为空字符串. 如果Body存在, 则在Header中会有一个Content-Length属性来标识Body的长度;
HTTP响应
-
首行: [版本号] + [状态码] + [状态码解释]
-
Header: 请求的属性, 冒号分割的键值对;每组属性之间使用\n分隔;遇到空行表示Header部分结束
-
- Content-Type: 数据类型(text/html等)
-
- Content-Length: Body的长度
-
- Host: 客户端告知服务器, 所请求的资源是在哪个主机的哪个端口上;
-
- User-Agent: 声明用户的操作系统和浏览器版本信息;
-
- referer: 当前页面是从哪个页面跳转过来的;
-
- location: 搭配3xx状态码使用, 告诉客户端接下来要去哪里访问;
-
- Cookie: 用于在客户端存储少量信息. 通常用于实现会话(session)的功能;
-
- …
-
Body: 空行后面的内容都是Body. Body允许为空字符串. 如果Body存在, 则在Header中会有一个Content-Length属性来标识Body的长度;如果服务器返回了一个html页面, 那么html页面内容就是在body中.
请求方法
| 方法 | 说明 | 支持的HTTP协议版本 |
|---|---|---|
| GET | 获取资源 | 1.0、1.1 |
| POST | 传输实体主体 | 1.0、1.1 |
| PUT | 传输文件 | 1.0、1.1 |
| HEAD | 获得报文首部 | 1.0、1.1 |
| DELETE | 删除文件 | 1.0、1.1 |
| OPTIONS | 询问支持的方法 | 1.1 |
| TRACE | 追踪路径 | 1.1 |
| CONNECT | 要求用隧道协议连接代理 | 1.1 |
| LINK | 建立和资源之间的联系 | 1.0 |
| UNLINE | 断开连接关系 | 1.0 |
HTTP状态码分类
| 分类 | 分类描述 |
|---|---|
| 1** | 信息，服务器收到请求，需要请求者继续执行操作 |
| 2** | 成功，操作被成功接收并处理 |
| 3** | 重定向，需要进一步的操作以完成请求 |
| 4** | 客户端错误，请求包含语法错误或无法完成请求 |
| 5** | 服务器错误，服务器在处理请求的过程中发生了错误 |
HTTP状态码列表
实现一个简单的HTTP服务器
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
void Usage() {
printf("usage: ./server [ip] [port]\n");
}
int main(int argc, char* argv[]) {
if (argc != 3) {
Usage();
return 1;
}
int fd = socket(AF_INET, SOCK_STREAM, 0);
if (fd < 0) {
perror("socket");
return 1;
}
struct sockaddr_in addr;
addr.sin_family = AF_INET;
addr.sin_addr.s_addr = inet_addr(argv[1]);
addr.sin_port = htons(atoi(argv[2]));
int ret = bind(fd, (struct sockaddr*)&addr, sizeof(addr));
if (ret < 0) {
perror("bind");
return 1;
}
ret = listen(fd, 10);
if (ret < 0) {
perror("listen");
return 1;
}
for (;;) {
struct sockaddr_in client_addr;
socklen_t len;
int client_fd = accept(fd, (struct sockaddr*)&client_addr, &len);
if (client_fd < 0) {
perror("accept");
continue;
}
char input_buf[1024 * 10] = { 0 }; // 用一个足够大的缓冲区直接把数据读完.
ssize_t read_size = read(client_fd, input_buf, sizeof(input_buf) - 1);
if (read_size < 0) {
return 1;
}
printf("[Request] %s", input_buf);
char buf[1024] = { 0 };
const char* hello = "<h1>hello world</h1>";
sprintf(buf, "HTTP/1.0 200 OK\nContent-Length:%lu\n\n%s", strlen(hello), hello);
write(client_fd, buf, strlen(buf));
}
return 0;
}
编译, 启动服务. 在浏览器中输入 http://[ip]:[port], 就能看到显示的结果 “Hello World”
URL
因特网上的可用资源可以用简单字符串来表示，该文档就是描述了这种字符串的语法和语义。而这些字符串则被称为：“统一资源定位器”（URL）。
urlencode和urldecode
像 / ? : 等这样的字符, 已经被url当做特殊意义理解了. 因此这些字符不能随意出现.
比如, 某个参数中需要带有这些特殊字符, 就必须先对特殊字符进行转义.
转义规则:
数字和字母不变、空格变为"+"号、其它字符转为16进制，然后从右到左，取4位2，每2位做一位，前面加上%，编码成%XY格式
"+" 被转义成了 "%2B"
"啊" 字被转义成了 %E5%95%8A
| 序号 | 特殊字符 | 含义 | 十六进制值 |
|---|---|---|---|
| 1 | + | URL 中+号表示空格 | %2B |
| 2 | 空格 | URL中的空格可以用+号或者编码 | %20 |
| 3 | / | 分隔目录和子目录 | %2F |
| 4 | ? | 分隔实际的 URL 和参数 | %3F |
| 5 | % | 指定特殊字符 | %25 |
| 6 | # | 表示书签 | %23 |
| 7 | & | URL 中指定的参数间的分隔符 | %26 |
| 8 | = | URL 中指定参数的值 | %3D |
对于包含汉字的url编码出现的情况会比较多，请参考文章：URL编码规则
urlencode和urldecode转化网站
端口号
端口号(Port)标识了一个主机上进行通信的不同的应用程序
在TCP/IP协议中, 用 “源IP”, “源端口号”, “目的IP”, “目的端口号”, “协议号” 这样一个五元组来标识一个通信(可以通过
netstat -n查看)
端口号范围划分
-
0 - 1023: 知名端口号, HTTP, FTP, SSH等这些广为使用的应用层协议, 他们的端口号都是固定的
-
1024 - 65535: 操作系统动态分配的端口号. 客户端程序的端口号, 就是由操作系统从这个范围分配的
知名端口号
- ssh服务器, 使用22端口
- ftp服务器, 使用21端口
- telnet服务器, 使用23端口
- http服务器, 使用80端口
- https服务器, 使用443
看到知名端口号：
cat /etc/services
netstat
netstat是一个用来查看网络状态的重要工具
语法：netstat [选项]
常用选项：
-
n 拒绝显示别名，能显示数字的全部转化成数字 -
l 仅列出有在 Listen (监听) 的服務状态 -
p 显示建立相关链接的程序名 -
t (tcp)仅显示tcp相关选项 -
u (udp)仅显示udp相关选项 -
a (all)显示所有选项，默认不显示LISTEN相关
pidof
通过进程名, 查看进程id
语法：pidof [进程名]
传输层
UDP协议
UDP协议段格式
16位UDP长度, 表示整个数据报(UDP首部+UDP数据)的最大长度;
如果校验和出错, 就会直接丢弃;
UDP协议首部中有一个16位的最大长度. 也就是说一个UDP能传输的数据(包含UDP首部)最大长度是64K
如果我们需要传输的数据超过64K, 就需要在应用层手动的分包, 多次发送, 并在接收端手动拼装;
UDP的特点
UDP的socket既能读, 也能写, 称为全双工
无连接
知道对端的IP和端口号就直接进行传输, 不需要建立连接;
不可靠
没有确认机制, 没有重传机制; 如果因为网络故障该段无法发到对方, UDP协议层也不会给应用层返回任何错误信息;
UDP没有真正意义上的 发送缓冲区. 调用sendto会直接交给内核, 由内核将数据传给网络层协议进行后续的传输动作;
UDP具有接收缓冲区. 但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致; 如果缓冲区满了, 再到达的UDP数据就会被丢弃;
面向数据报
不能够灵活的控制读写数据的次数和数量;应用层交给UDP多长的报文, UDP原样发送, 既不会拆分, 也不会合并;
用UDP传输100个字节的数据:如果发送端调用一次sendto, 发送100个字节, 那么接收端也必须调用对应的一次recvfrom, 接收100个
字节; 而不能循环调用10次recvfrom, 每次接收10个字节;
基于UDP的应用层协议
-
NFS: 网络文件系统
-
TFTP: 简单文件传输协议
-
DHCP: 动态主机配置协议
-
BOOTP: 启动协议(用于无盘设备启动)
-
DNS: 域名解析协议
TCP3
TCP协议段格式
- 源/目的端口号: 表示数据是从哪个进程来, 到哪个进程去;
- 32位序号/32位确认号: 后面详细讲;
- 4位TCP报头长度: 表示该TCP头部有多少个32位bit(有多少个4字节); 所以TCP头部最大长度是15 * 4 = 60
- 6位标志位:
-
- URG: 紧急指针是否有效
-
- ACK: 确认号是否有效
-
- PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走
-
- RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段
-
- SYN: 请求建立连接; 我们把携带SYN标识的称为同步报文段
-
- FIN: 通知对方, 本端要关闭了, 我们称携带FIN标识的为结束报文段
- 16位窗口大小: TCP (传输控制协议)是一个面向连接的协议。发送方发送数据，接收方会对其响应ACK，如果接收方没有按时响应ACK，发送方将重传数据。TCP使用“窗口”，意味着发送方发送一个或更多数据包，接收方就会响应一个或所有数据包。当接收方开始一个TCP连接时，自身会打开一个接收缓存区作为临时存储，之后再交给程序处理。当接收方发送一个ACK响应(即对收到数据的响应)时，接收方会告诉发送者下一次我能接收多少数据，我们管这个叫窗口大小(window size)。一般这个窗口大小就是接收方缓冲区的大小。
- 16位校验和: 发送端填充, CRC校验. 接收端校验不通过, 则认为数据有问题. 此处的检验和不光包含TCP首部, 也
- 包含TCP数据部分.
- 16位紧急指针: 标识哪部分数据是紧急数据;
- 40字节头部选项: 暂时忽略;
连接管理机制
TCP要经过三次握手建立连接, 四次挥手断开连接
上半部分是TCP三路握手过程的状态变迁，下半部分是TCP四次挥手过程的状态变迁
-
CLOSED：起始点，在超时或者连接关闭时候进入此状态，这并不是一个真正的状态，而是这个状
态图的假想起点和终点。 -
LISTEN：服务器端等待连接的状态。服务器经过 socket，bind，listen 函数之后进入此状态，开
始监听客户端发过来的连接请求。此称为应用程序被动打开（等到客户端连接请求）。 -
SYN_SENT：第一次握手发生阶段，客户端发起连接。客户端调用 connect，发送 SYN 给服务器
端，然后进入 SYN_SENT 状态，等待服务器端确认（三次握手中的第二个报文）。如果服务器端
不能连接，则直接进入CLOSED状态。 -
SYN_RCVD：第二次握手发生阶段，跟 3 对应，这里是服务器端接收到了客户端的 SYN，此时服务器由 LISTEN 进入 SYN_RCVD状态，同时服务器端回应一个 ACK，然后再发送一个 SYN 即SYN+ACK 给客户端。状态图中还描绘了这样一种情况，当客户端在发送 SYN 的同时也收到服务器端的 SYN请求，即两个同时发起连接请求，那么客户端就会从 SYN_SENT 转换到 SYN_REVD 状态。
-
ESTABLISHED：第三次握手发生阶段，客户端接收到服务器端的 ACK 包（ACK，SYN）之后，也会发送一个 ACK 确认包，客户端进入 ESTABLISHED 状态，表明客户端这边已经准备好，但TCP需要两端都准备好才可以进行数据传输。服务器端收到客户端的 ACK 之后会从 SYN_RCVD 状态转
移到 ESTABLISHED 状态，表明服务器端也准备好进行数据传输了。这样客户端和服务器端都是ESTABLISHED 状态，就可以进行后面的数据传输了。所以 ESTABLISHED 也可以说是一个数据传送状态。
下面是TCP四次挥手过程的状态变迁。
-
FIN_WAIT_1：第一次挥手。主动关闭的一方（执行主动关闭的一方既可以是客户端，也可以是服
务器端，这里以客户端执行主动关闭为例），终止连接时，发送 FIN 给对方，然后等待对方返回
ACK 。调用 close() 第一次挥手就进入此状态。 -
CLOSE_WAIT：接收到FIN 之后，被动关闭的一方进入此状态。具体动作是接收到 FIN，同时发送ACK。之所以叫 CLOSE_WAIT 可以理解为被动关闭的一方此时正在等待上层应用程序发出关闭连接指令。TCP关闭是全双工过程，这里客户端执行了主动关闭，被动方服务器端接收到FIN 后也需要调用 close 关闭，这个 CLOSE_WAIT 就是处于这个状态，等待发送 FIN，发送了FIN 则进入LAST_ACK 状态。
-
FIN_WAIT_2：主动端（这里是客户端）先执行主动关闭发送FIN，然后接收到被动方返回的 ACK后进入此状态。
-
LAST_ACK：被动方（服务器端）发起关闭请求，由状态2 进入此状态，具体动作是发送 FIN给对方，同时在接收到ACK 时进入CLOSED状态。
-
CLOSING：两边同时发起关闭请求时（即主动方发送FIN，等待被动方返回ACK，同时被动方也发送了FIN，主动方接收到了FIN之后，发送ACK给被动方），主动方会由FIN_WAIT_1 进入此状态，等待被动方返回ACK。
-
TIME_WAIT：从状态变迁图会看到，四次挥手操作最后都会经过这样一个状态然后进入CLOSED状态。
| 状态 | 描述 |
|---|---|
| CLOSED | 阻塞或关闭状态，表示主机当前没有正在传输或者建立的链接 |
| LISTEN | 监听状态，表示服务器做好准备，等待建立传输链接 |
| SYN RECV | 收到第一次的传输请求，还未进行确认 |
| SYN SENT | 发送完第一个SYN报文，等待收到确认 |
| ESTABLISHED | 链接正常建立之后进入数据传输阶段 |
| FIN WAIT1 | 主动发送第一个FIN报文之后进入该状态 |
| FIN WAIT2 | 已经收到第一个FIN的确认信号，等待对方发送关闭请求 |
| TIMED WAIT | 完成双向链接关闭，等待分组消失 |
| CLOSING | 双方同时关闭请求，等待对方确认时 |
| CLOSE WAIT | 收到对方的关闭请求并进行确认进入该状态 |
| LAST ACK | 等待最后一次确认关闭的报文 |
三次握手
1）第一次握手：建立连接时，客户端向服务器发送SYN包（seq=x），请求建立连接，等待确认
2）第二次握手：服务端收到客户端的SYN包，回一个ACK包（ACK=x+1）确认收到，同时发送一个SYN包（seq=y）给客户端
3）第三次握手：客户端收到SYN+ACK包，再回一个ACK包（ACK=y+1）告诉服务端已经收到
4）三次握手完成，成功建立连接，开始传输数据
回复的ack包的序列号是接收的syn包的序列号+1
说说 TCP 2次握手行不行？为什么要3次
-
为了实现可靠数据传输， TCP 协议的通信双方， 都必须维护一个序列号， 以标识发送出去的数据包中， 哪些是已经被对方收到的。三次握手的过程即是通信双方相互告知序列号起始值， 并确认对方已经收到了序列号起始值的必经步骤
-
如果只是两次握手， 至多只有连接发起方的起始序列号能被确认， 另一方选择的序列号则得不到
确认
确认应答(ACK)机制和四次挥手
确认应答(ACK)机制
每一个ACK都带有对应的确认序列号, 意思是告诉发送者, 我已经收到了哪些数据; 并且让发送方知道下一次从哪里开始发
TCP将每个字节的数据都进行了编号. 即为序列号
四次挥手
通过上面的确认应答机制，我们就可以清楚知道，响应序列号为什么是在对方发送序列号的基础上+1进行回复的
1）客户端发送FIN包（FIN=1）给服务端，告诉它自己的数据已经发送完毕，请求终止连接，此时客户端不发送数据，但还能接收数据
2）服务端收到FIN包，回一个ACK包给客户端告诉它已经收到包了，此时还没有断开socket连接，而是等待剩下的数据传输完毕
3）服务端等待数据传输完毕后，向客户端发送FIN包，表明可以断开连接
4）客户端收到后，回一个ACK包表明确认收到，等待一段时间，确保服务端不再有数据发过来，然后彻底断开连接
超时重传机制
主机A发送数据给B之后, 可能因为网络拥堵等原因, 数据无法到达主机B;
如果主机A在一个特定时间间隔内没有收到B发来的确认应答(主机A未收到B发来的确认应答, 也可能是因为ACK丢失了), 就会进行重发
确认应答步骤丢ACK包就会触发重传机制，而接收方会收到重复的包，TCP协议就是通过包的序列号进行去重的
TCP在发送数据时会设置一个计时器，若到计时器超时仍未收到数据确认信息，则会引发相应的超时或基于计时器的重传操作，计时器超时称为 重传超时（RTO） 。另一种方式的重传称为 快速重传，通常发生在没有延时的情况下。若TCP累积确认无法返回新的ACK，或者当ACK包含的选择确认信息（SACK）表明出现失序报文时，快速重传会推断出现丢包，需要重传。
超时机制的动态确定时长
超时时间设置太长，会导致重传效率降低；超时时长设置太短，会频繁发送重复的包。TCP为了保证无论在任何环境下都能比较高性能的通信, 因此会动态计算这个最大超时时间
Linux中(BSD Unix和Windows也是如此), 超时以500ms为一个单位进行控制, 每次判定超时重发的超时时间都是500ms的整数倍.
-
如果重发一次之后, 仍然得不到应答, 等待 2*500ms 后再进行重传.
-
如果仍然得不到应答, 等待 4*500ms 进行重传. 依次类推, 以指数形式递增.
-
累计到一定的重传次数, TCP认为网络或者对端主机出现异常, 强制关闭连接.
滑动窗口
确认应答策略, 对每一个发送的数据段, 都要给一个ACK确认应答. 收到ACK后再发送下一个数据段。这样做有一个比较大的缺点, 就是性能较差。尤其是数据往返的时间较长的时候。滑动窗口大小一次可以容纳多个段，连续发送窗口大小4所能容纳的段，期间不需要等待任何ACK，一旦收到第一个ACK后, 滑动窗口向后移动, 继续发送滑动窗口大小所能容纳的段。
操作系统内核为了维护这个滑动窗口, 需要开辟发送缓冲区来记录当前还有哪些数据没有应答; 只有确认应答过的数据, 才能从缓冲区删掉;窗口越大, 则网络的吞吐率就越高。
滑动窗口协议是传输层进行流控的一种措施，接收方通过通告发送方自己的窗口大小，从而控制发送方的发送速度，从而达到防止发送方发送速度过快而导致自己被淹没的目的。TCP的滑动窗口解决了端到端的流量控制问题，允许接受方对传输进行限制，直到它拥有足够的缓冲空间来容纳更多的数据。
滑动窗口方式出现了丢包, 如何进行重传
- 数据包已经抵达, ACK被丢了
中间部分ACK丢了并不要紧, 因为可以通过后续的ACK进行确认
- 数据包就直接丢了
-
假设丢失的包是1001~2000数据包
-
当这一段报文段丢失之后, 发送端会一直收到 1001 这样的ACK
-
如果发送端主机连续三次收到了同样一个 “1001” 这样的应答, 就会将对应的数据 1001 - 2000 重新发送;
-
这个时候接收端收到了 1001 之后, 再次返回的ACK就是接收端之前就已经收到的最后一个段的尾+1(比如之前已经收到了2001 - 7000，则再返回的ACK就是7001了)
流量控制
接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送,就会造成丢包,继而引起丢包重传等等一系列连锁反应.因此TCP支持根据接收端的处理能力, 来决定发送端的发送速度. 这个机制就叫做流量控制(Flow Control);
-
接收端将自己可以接收的缓冲区大小放入 TCP 首部中16位的 “窗口大小5字段” , 通过ACK段通知发送端;
-
接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端;发送端接受到这个窗口之后, 就会减慢自己的发送速度;
-
如果接收端缓冲区满了, 就会将窗口置为0; 这时发送方不再发送数据, 但是需要定期发送一个窗口探测数据段, 使接收端把窗口大小告诉发送端.
实际窗口大小计算
TCP首部40字节选项中还包含了一个窗口扩大因子 M, 实际窗口大小是16位窗口字段的值左移 M 位
拥塞控制
有滑动窗口和流量控制机制, 能够高效可靠的发送大量的数据. 但是如果在刚开始阶段就发送大量的数据, 仍然可能引发问题
当前的网络状态就已经比较拥堵. 在不清楚当前网络状态下, 贸然发送大量的数据,很容易引发丢包和重传
TCP引入慢启动机制, 先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据;
拥塞窗口
-
发送开始的时候, 定义拥塞窗口大小为常数(1);
-
每次收到一个ACK应答, 拥塞窗口增大6(指数或者线性增长);
-
每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的窗口大小做比较, 取较小的值作为实际发送的窗口;
拥塞窗口变化曲线
当TCP开始启动的时候, 慢启动阈值等于窗口最大值;
在每次超时重发的时候, 慢启动阈值会变成原来的一半, 同时拥塞窗口置回1;
少量的丢包, 我们仅仅是触发超时重传; 大量的丢包, 我们就认为网络拥塞;
当TCP通信开始后, 网络吞吐量会逐渐上升; 随着网络发生拥堵, 吞吐量会立刻下降;
拥塞控制, 归根结底是TCP协议想尽可能快的把数据传输给对方, 但是又要避免给网络造成太大压力的折中方案.
延迟应答
接收数据的主机立刻返回ACK应答， 接收缓冲区中的数据还没能够处理，缓存区的剩余大小就是窗口大小，这时候返回的窗口可能比较小，因此延时应答可以使得返回的窗口变大。窗口越大, 网络吞吐量就越大, 传输效率就越高，目标是在保证网络不拥塞的情况下尽量提高传输效率;
不是所有的情况下都可以延迟应答
-
数量限制: 每隔N个包就应答一次;
-
时间限制: 超过最大延迟时间就应答一次;
具体的数量和超时时间, 依操作系统不同也有差异; 一般N取2, 最大延迟时间取200ms
捎带应答
当客户端服务端在应用层是一发一响应的方式时。那么延迟应答就随着响应ACK一块发送给服务器了
面向字节流
创建一个TCP的socket, 同时在内核中创建一个发送缓冲区和一个接收缓冲区,这个连接既可以发数据也可以收数据，是全双工的通信
-
调用write时, 数据会先写入发送缓冲区中7, 再通过网卡发送出去
-
接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;然后应用程序可以调用read从接收缓冲区拿数据
发送和接收缓冲区最大的作用就是对读和写的过程进行解耦，读和写的速度不需要匹配
粘包问题
发送方引起的粘包是由TCP协议本身造成的，TCP为提高传输效率，发送方往往要收集到足够多的数据后才发送一个TCP段。若连续几次需要send的数据都很少，通常TCP会根据优化算法把这些数据合成一个TCP段后一次发送出去，这样接收方就收到了粘包数据。
TCP协议是面向流的协议,TCP协议层会把构成整条消息的数据段排序完成后才呈现在内核缓冲区,应用程序所看到的数据是一个整体，或说是一个流（stream）。应用程序必须以消息为单位提取数据，而一条消息有多少字节对应用程序是不可见的, 接收方不知道消息之间的界限，这就是粘包。
避免粘包问题
本质上就是区分包之间的边界，实际上就是在应用层自己实现stream2datagram的过程，靠设计一个带包头的应用层报文结构就能解决
-
包头定长，以特定标志开头，里带着负载长度，这样接收侧只要以定长尝试读取包头，再按照包头里的负载长度读取负载就行了，多出来的数据都留在缓冲区里即可。
-
对于变长的包, 可以在包头的位置, 约定一个包总长度的字段, 从而就知道了包的结束位置, 还可以在包和包之间使用明确的分隔符8
UDP不会粘包
UDP是无连接的、面向消息的，提供高效率服务的协议。不会使用块的合并优化算法，由于UDP支持的是一对多的模式，所以接收端的skbuff(套接字缓冲区）采用了链式结构来记录每一个到达的UDP包，在每个UDP包中就有了消息头（消息来源地址，端口等信息），这样，对于接收端来说，就容易进行区分处理了。 即面向消息的通信是有消息保护边界的。
每个UDP段都是一条消息，应用程序必须以消息为单位提取数据，不能一次提取任意字节的数据
TCP异常情况
FIN终止
进程终止或者机器重启导致的进程终止，会先释放文件描述符, 仍然可以发送FIN，和正常关闭没有什么区别
reset
机器掉电/网线断开：对方有写入操作, 发现连接已经不在了, 就会进行reset;或者TCP内置的保活定时器, 会定期询问对方是否还在. 如果对方不在, 也会把连接释放
应用层一些检测机制：比如HTTP长连接中, 也会定期检测对方的状态. 例如QQ, 在QQ断线之后, 也会定期尝试重新连接.
TCP/UDP对比
TCP 和 UDP 的区别及头部结构
什么是 MSL，为什么客户端连接要等待2MSL的时间才能完全关闭?
- MSL是Maximum Segment Lifetime的英文缩写，可译为“最长报文段寿命”，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。
为了保证客户端发送的最后一个ACK报文段能够到达服务器。因为这个ACK有可能丢失，从而导致处在LAST-ACK状态的服务器收不到对FIN-ACK的确认报文。服务器会超时重传这个FIN-ACK，接着客户端再重传一次确认，重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待2MSL，而是在发送完ACK之后直接释放关闭，一但这个ACK丢失的话，服务器就无法正常的进入关闭连接状态。
- 两个理由：
保证客户端发送的最后一个ACK报文段能够到达服务端。这个ACK报文段有可能丢失，使得处于LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认，服务端超时重传FIN+ACK报文段，而客户端能在2MSL时间内收到这个重传的FIN+ACK报文段，接着客户端重传一次确认，重新启动2MSL计时器，最后客户端和服务端都进入到CLOSED状态，若客户端在TIME-WAIT状态不等待一段时间，而是发送完ACK报文段后立即释放连接，则无法收到服务端重传的FIN+ACK报文段，所以不会再发送一次确认报文段，则服务端无法正常进入到CLOSED状态。
防止“已失效的连接请求报文段”出现在本连接中。
客户端在发送完最后一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生
的所有报文段都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文段。
-
超文本传输协议:hyper Text Transfer protocol ↩︎
-
不足4位直接处理 ↩︎
-
Transmission Control Protocol ↩︎
-
窗口大小指的是无需等待确认应答而可以继续发送数据的最大值 ↩︎
-
窗口大小字段越大, 说明网络的吞吐量越高 ↩︎
-
没有超过慢启动的阈值时，拥塞窗口呈指数倍增长，超过这个阈值的时候, 按照线性方式增长 ↩︎
-
如果发送的字节数太长, 会被拆分成多个TCP的数据包发出;
如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出
去 ↩︎ -
应用层协议, 是程序猿自己来定的, 只要保证分隔符不和正文冲突即可 ↩︎