网络基础2

应用层

HTTP协议

虽然我们说, 应用层协议是我们程序猿自己定的.
但实际上, 已经有大佬们定义了一些现成的, 又非常好用的应用层协议, 供我们直接参考使用. HTTP(超文本传输协议)就是其中之一.

认识URL

平时我们俗称的 “网址” 其实就是说的 URL

URL，全称为Uniform Resource Locator（统一资源定位符），是互联网上用于标识、定位和访问特定资源的一种标准化方法。它是一种全球通用的地址格式，使得用户可以通过浏览器、应用程序或其他网络工具，准确无误地找到并访问互联网上的各种信息和服务。

一个完整的URL通常由以下几个部分组成：

• 协议（Protocol）：指定了访问资源所使用的网络协议，如HTTP（超文本传输协议）、HTTPS（安全超文本传输协议）、FTP（文件传输协议）等。这部分以“:”结束，位于URL的最开始。

• 域名（Domain Name）：即网站的地址，用于识别和定位互联网上的服务器。

• 端口（Port）：指定服务器上接收请求的服务端口，默认情况下，HTTP协议使用端口80，HTTPS协议使用端口443。如果不指定端口，浏览器会使用默认端口。端口与域名之间用“:”分隔。

• 路径（Path）：指定了服务器上资源的具体位置。路径以“/”开头，可以包含多级目录和文件名。

• 查询参数（Query Parameters）：当需要向服务器传递额外数据或指定资源的特定版本时，可以使用查询字符串。查询字符串紧跟在路径后面，以“?”开始，各参数之间用“&”分隔。每个参数由键值对组成，键与值之间用“=”连接。

• 片段标识符（Fragment Identifier）：用于指示网页内部特定位置的标签（如HTML中的id属性）。片段标识符以“#”开始，后跟标识符名称。浏览器不会将片段标识符发送到服务器，而是在页面加载后，自行滚动到带有相应ID的元素处。

www.baidu.com表示的是服务器地址，也叫做域名。
需要注意的是，我们用IP地址标识公网内的一台主机，但IP地址本身并不适合给用户看。比如说我们可以通ping命令获得www.baidu.com的域名解析后的IP地址。

域名与IP地址之间存在一对一或多对一的映射关系。一个域名可以映射到一个或多个IP地址上，而一个IP地址也可以对应多个域名。这种映射通过DNS（Domain Name System，域名系统）服务实现。

urlencode和urldecode

像 / ? : 等这样的字符, 已经被url当做特殊意义理解了. 因此这些字符不能随意出现。

转义的规则如下:
将需要转码的字符转为16进制，然后从右到左，取4位(不足4位直接处理)，每2位做一位，前面加上%，编码成%XY格式。
汉字也是要进行编码的。
urlencode工具

HTTP协议格式

http请求格式

下面的TCP服务器的功能会对浏览器发送过来的HTTP请求进行打印。

#include <iostream>
#include <string.h>
#include <sys/types.h>      
#include <sys/socket.h>
#include <arpa/inet.h> //struct sockaddr_in
#include <unistd.h>
#include <sys/wait.h>
#include <stdlib.h>
const static uint16_t port = 8888;
int main()
{//创建套接字int listen_sock = socket(AF_INET, SOCK_STREAM, 0);//AF_INET 表示网络通信//SOCK_STREAM 流式套接if(-1 == listen_sock){std::cerr << " socket create error" << std::endl;return 1;}//绑定struct sockaddr_in local;memset(&local, 0, sizeof(local));local.sin_family = AF_INET;                // 通信方式local.sin_port = htons(port);              // 端口号local.sin_addr.s_addr = htonl(INADDR_ANY); // ip地址if(-1 == bind(listen_sock,(struct sockaddr*)&local, sizeof(local))){std::cerr << "socket bind error" << std::endl;return 2;}//监听if(listen(listen_sock, 32) == -1){std::cerr << "socket listen error" << std::endl;return 2;}while(true){//获取链接struct sockaddr_in client;socklen_t len = sizeof(client);int sock = accept(listen_sock, (struct sockaddr*)&client, &len);if (sock == -1){std::cerr << "accept error" << std::endl;return 3;}int ret = fork();if(ret == -1){std::cerr << "fork create error" << std::endl;return 4;}else if(ret > 0){waitpid(-1,nullptr,0);}else if (ret == 0){int _ret = fork();if (_ret == -1){std::cerr << "fork fork create error" << std::endl;return 5;}else if (_ret > 0){close(listen_sock);exit(0);}//孤儿进程会被1号进程领养char buffer[4096];ssize_t s = recv(sock, buffer, sizeof(buffer) - 1, 0); // 我们认为我们能一次读完buffer[s] = '\0';std::cout << "---------------------------------------" << std::endl;std::cout << buffer << std::endl;std::cout << "---------------------------------------" << std::endl;close(sock);exit(0);}close(sock);}return 0;
}

浏览器向我们的服务器发起HTTP请求后，因为我们的服务器没有对进行响应，此时浏览器就会认为服务器没有收到，然后再不断发起新的HTTP请求，因此虽然我们只用浏览器访问了一次，但会受到多次HTTP请求。
URL当中的/不能称之为我们云服务器上根目录，这个/表示的是web根目录，这个web根目录可以是你的机器上的任何一个目录，这个是可以自己指定的，不一定就是Linux的根目录。

如果浏览器在访问我们的服务器时指明要访问的资源路径，那么此时浏览器发起的HTTP请求当中的url也会跟着变成该路径。

http响应格式

#include <iostream>
#include <string.h>
#include <sys/types.h>      
#include <sys/socket.h>
#include <arpa/inet.h> //struct sockaddr_in
#include <unistd.h>
#include <sys/wait.h>
#include <stdlib.h>
const static uint16_t port = 8888;
const std::string SEP = "\r\n";
int main()
{//创建套接字int listen_sock = socket(AF_INET, SOCK_STREAM, 0);//AF_INET 表示网络通信//SOCK_STREAM 流式套接if(-1 == listen_sock){std::cerr << " socket create error" << std::endl;return 1;}//绑定struct sockaddr_in local;memset(&local, 0, sizeof(local));local.sin_family = AF_INET;                // 通信方式local.sin_port = htons(port);              // 端口号local.sin_addr.s_addr = htonl(INADDR_ANY); // ip地址if(-1 == bind(listen_sock,(struct sockaddr*)&local, sizeof(local))){std::cerr << "socket bind error" << std::endl;return 2;}//监听if(listen(listen_sock, 32) == -1){std::cerr << "socket listen error" << std::endl;return 2;}while(true){struct sockaddr_in client;socklen_t len = sizeof(client);int sock = accept(listen_sock, (struct sockaddr*)&client, &len);if (sock == -1){std::cerr << "accept error" << std::endl;return 3;}int ret = fork();if(ret == -1){std::cerr << "fork create error" << std::endl;return 4;}else if(ret > 0){waitpid(-1,nullptr,0);}else if (ret == 0){int _ret = fork();if (_ret == -1){std::cerr << "fork fork create error" << std::endl;return 5;}else if (_ret > 0){close(listen_sock);exit(0);}//孤儿进程会被1号进程领养char buffer[4096];ssize_t s = recv(sock, buffer, sizeof(buffer) - 1, 0); // 我们认为我们能一次读完buffer[s] = '\0';std::cout << "---------------------------------------" << std::endl;std::string response = "HTTP/1.0 200 OK" + SEP;//状态行response += SEP;//空行response += "hello Http";//有效载荷//有效载荷部分，通常是以网页的方式进行呈现的send(sock,response.c_str(),response.size(), 0);std::cout << "---------------------------------------" << std::endl;close(sock);exit(0);}close(sock);}return 0;
}

🔎 http如何将报头与有效载荷如何分离的？
逐行读取，从网络流中按行读取数据。每读取到一行，检查是否为键值对形式的报头行。识别空行，继续读取，直到遇到一个仅由\r\n组成的行，即空行。这个空行标志着报头部分的结束。截断报头，将读取到空行之前的所有数据视为报头，对其进行解析，提取出各个报头字段及其对应的值。读取有效载荷，空行之后的数据被视为有效载荷。

🔎 http如果请求协议版本与http响应协议版本如果不同，服务器是如何响应的那？
当客户端发起HTTP请求时，会在请求行中明确指定所使用的HTTP版本。这是客户端向服务器告知其协议能力的方式。服务器接收到请求后，识别并依据客户端声明的HTTP版本进行响应处理。服务器会调整响应的格式以符合客户端所使用的版本规范，确保双方能够正常通信，避免版本差异带来的问题。HTTP协议中，客户端与服务器关于版本信息的交互并非双向交流，而是客户端单向告知其版本，服务器通过使用相同版本构建响应进行确认。

HTTP的方法

方法	说明	支持的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
UNLINK	断开连接关系	1.0

GET与POST的区别

GET

POST

GET，POST差别，他们各自的应用场景是什么?
GET方法提交参数，不私密。POST提交参数比较私密一些。这两种方法都不是安全。
所有的登陆注册支付等行为，都要使用POST(不是只用)方法提参。
url: http请求行字符串，一般都会有大小的约束，正文，理论上可以非常大。

HTTP的状态码

	类别	原因短语
1XX	Informational（信息性状态码）	接收的请求正在处理
2XX	Success（成功状态码）	请求正常处理完毕
3XX	Redirection（重定向状态码）	需要进行附加操作以完成请求
4XX	Client Error（客户端错误状态码）	服务器无法处理请求
5XX	Server Error（服务器错误状态码）	服务器处理请求出错

最常见的状态码, 比如 200(OK), 404(Not Found), 403(Forbidden), 302(Redirect, 重定向), 504(Bad Gateway)

重定向又可分为临时重定向和永久重定向，其中状态码301表示的就是永久重定向，而状态码302和307表示的是临时重定向。
临时重定向： 当客户端（如浏览器）收到302状态码时，它会自动访问新的URL，但仍然保留对原URL的请求历史。后续对该资源的请求，客户端可能会再次尝试访问原URL，除非得到明确指示或缓存失效。
永久重定向： 收到301状态码时，客户端不仅会自动跳转到新的URL，还会更新其内部记录（如浏览器的历史记录、书签），将原URL替换为新的URL。后续请求会直接指向新的URL，除非用户手动清除缓存或有其他更新。

HTTP常见Header

• Content-Type：数据类型（text/html等）。
• Content-Length：正文的长度。
• Host：客户端告知服务器，所请求的资源是在哪个主机的哪个端口上。
• User-Agent：声明用户的操作系统和浏览器的版本信息。
• Referer：当前页面是哪个页面跳转过来的。
• Location：搭配3XX状态码使用，告诉客户端接下来要去哪里访问。
• Cookie：用于在客户端存储少量信息，通常用于实现会话（session）的功能。

Cookie与Session

HTTP本身是无状态的，这意味着它在处理请求和响应时不会保留任何关于之前交互的上下文信息。
以下是无状态特性的详细解释： 每个请求独立处理，在无状态协议下，每个HTTP请求被视为独立的事务，服务器不依赖于任何关于客户端过去行为的知识来处理当前请求。客户端每次发起请求时，必须在请求中包含所有必需的信息，以便服务器能够理解请求的目的并生成适当的响应。

但是我们在使用浏览器的访问CSDN(或其他需要登录的网站)只要首次登录过，下次在访问时，我们发现CSDN已经处于登录状态了，就算你把CSDN网站关了甚至是重启电脑，当你再次打开CSDN网站时，还是是登录状态。

HTTP是超文本传输协议，HTTP不直接做这个工作，但是HTTP提供了这个功能，因为用户需要—会话保持。

cookie是什么呢？
浏览器在访问需要登录的服务的vip资源时，首先浏览器向服务器发送请求，服务器收到了浏览器的请求，如果服务器检测到浏览器没有登录，对浏览器的响应就是要求浏览器进行登录。浏览器登录上用户名与密码后在向服务发送请求，服务器会对收到用户密码做认证，只要认证通过，服务器在对浏览器的响应中，会将选项Set-Cooke: 私人信息(用户名密码等)携带到Http响应里。当浏览器收到的响应里Set-Cooke: ,会将Set-Cooke: 的右值进行本地保存(内存级，文件级)。以后浏览器在访问相同的网站时，浏览器会在后续的Http请求中会携带Set-Cooke: 保存的历史cooke信息，不用用户进行手动操作，这是浏览器自动做的。

如果你浏览器当中保存的cookie信息被非法用户盗取了，那么此时这个非法用户就可以用你的cookie信息，以你的身份去访问你曾经访问过的网站，我们将这种现象称为cookie被盗取了。
Sessionid是什么呢？

非法用户虽然还能盗取了你的cooke，以你的身份也去访问对应的目标网站了，这个问题还是会存在。但是我们不用担心用户的个人的私人信息被泄露了，因为用户私人的信息已经被服务器维护起来了，浏览器与服务器用sessionid进行交互。

传输层

传输层：主要任务提供传输策略。

在谈端口号

端口号：标识本主机上的唯一的网络进程。
在TCP/IP协议中, 用 “源IP”, “源端口号”, “目的IP”, “目的端口号”, “协议号” 这样一个五元组来标识一个通信(可以通过netstat -n查看);

端口号范围划分

端口号是2个字节16位整数uint16_t

• 0 - 1023: 知名端口号, HTTP, FTP, SSH等这些广为使用的应用层协议, 他们的端口号都是固定的.
• 1024 - 65535: 操作系统动态分配的端口号. 客户端程序的端口号, 就是由操作系统从这个范围分配的

认识知名端口号

有些服务器是非常常用的, 为了使用方便, 人们约定一些常用的服务器, 都是用以下这些固定的端口号:

• ssh服务器, 使用22端口
• ftp服务器, 使用21端口
• telnet服务器, 使用23端口
• http服务器, 使用80端口
• https服务器, 使用443端口

netstat

netstat是一个用来查看网络状态的重要工具.
语法：netstat [选项]
功能：查看网络状态
常用选项：

• n 拒绝显示别名，能显示数字的全部转化成数字
• l 仅列出有在 Listen (监听) 的服務状态
• p 显示建立相关链接的程序名
• t (tcp)仅显示tcp相关选项
• u (udp)仅显示udp相关选项
• a (all)显示所有选项，默认不显示LISTEN相关

pidof

在查看服务器的进程id时非常方便.
语法：pidof [进程名]
功能：通过进程名, 查看进程id

UDP协议

UDP协议端格式

• 16位UDP长度, 表示整个数据报(UDP首部+UDP数据)的最大长度;
• 如果校验和出错, 就会直接丢弃，如果UDP的报文有残缺，UDP所对应的检验和就无法通过，UDP就将报文丢弃。

这种报文(报文=报头 + 有效载荷)是如何进行封装与解包的那？

UDP的特点

• 无连接: 知道对端的IP和端口号就直接进行传输, 不需要建立连接;
• 不可靠: 没有确认机制, 没有重传机制; 如果因为网络故障该段无法发到对方, UDP协议层也不会给应用层返回任何错误信息;
• 面向数据报: 不能够灵活的控制读写数据的次数和数量

面向数据报

应用层交给UDP多长的报文, UDP原样发送, 既不会拆分, 也不会合并;
用UDP传输100个字节的数据:

• 如果发送端调用一次sendto, 发送100个字节, 那么接收端也必须调用对应的一次recvfrom, 接收100个字节; 而不能循环调用10次recvfrom, 每次接收10个字节

UDP的缓冲区

• UDP没有真正意义上的 发送缓冲区. 调用sendto会直接交给内核, 由内核将数据传给网络层协议进行后续的传输动作;
• UDP具有接收缓冲区. 但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致; 如果缓冲区满了, 再到达的UDP数据就会被丢弃;

UDP的socket既能读, 也能写, 这个概念叫做 全双工

UDP使用注意事项

我们注意到, UDP协议首部中有一个16位的最大长度. 也就是说一个UDP能传输的数据最大长度是64K(包含UDP首部).
然而64K在当今的互联网环境下, 是一个非常小的数字.
如果我们需要传输的数据超过64K, 就需要在应用层手动的分包, 多次发送, 并在接收端手动拼装;

TCP协议

客户端和服务端，客户端可以给服务器发送消息。服务器当然也可以给客户端以同样的模式发送消息。TCP通信的本质其实是把自己发送缓冲区的内容拷贝到对方的接收缓冲区，对方把自己发送缓冲区的内容拷贝到自己的接收缓冲区。因为是成对的，所以发和收，发和收可以同时进行，所以我们称TCP协议是全双工
TCP全称为 “传输控制协议(Transmission Control Protocol”). 人如其名, 要对数据的传输进行一个详细的控制。

TCP协议段格式

报头 = 20字节标准报头 + 选项

TCP报头当中各个字段的含义如下：

• 源/目的端口号： 表示数据是从哪个进程来, 到哪个进程去。
• 32位序号/32位确认序号：分别代表TCP报文当中每个字节数据的编号以及对对方的确认，是TCP保证可靠性的重要字段。
• 4位首部长度：表示该TCP报头的长度，以4字节为单位。
• 6位保留字段：TCP报头中暂时未使用的6个比特位。
• 16位窗口大小：进行流量控制的，保证TCP可靠性机制和效率提升机制的重要字段。自己接收缓冲区的剩余空间大小，进行流量控制(增大或减小)
• 16位检验和：由发送端填充，采用CRC校验。接收端校验不通过，则认为接收到的数据有问题。（检验和包含TCP首部+TCP数据部分）
• 16位紧急指针：标识紧急数据在报文中的偏移量，需要配合标志字段当中的URG字段统一使用。
• 选项字段：TCP报头当中允许携带额外的选项字段。

6位标志位: 表示服务端在同一时刻收到的各种各样的报文请求，根据不同的报文提供不同对应的处理动作,这六个标志位都只占用一个比特位，为0表示假，为1表示真。

• URG: 紧急指针是否有效
• ACK: 确认号是否有效
• PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走
• RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段
• SYN: 请求建立连接; 我们把携带SYN标识的称为同步报文段
• FIN: 通知对方, 本端要关闭了, 我们称携带FIN标识的为结束报文段

🔎 TCP如何将报头与有效载荷进行分离？
TCP报文段开始的部分是固定的，通常包括20字节的标准报头。当TCP接收到一个报文段时，首先读取这前20个字节。并从中提取出4位的首部长度，首部长度 * 4 = 标准报头 + 选择字段的大小。如果首部长度 * 4 的等于20字节，就证明选项没有携带数据，此时首部长度的二进制位0101(十进制为5)，这也是首部长度的最小值。如果首部长度 * 4 的大于20字节，首部长度 * 4 - 20字节(标准报头长度)剩下的都是选项携带的数据大小。一旦确定了整个TCP头部的大小（包括任何选项），就可以据此分离出报头部分和跟随其后的有效载荷（用户数据）。

URG

TCP缓冲区的数据必须要按序到达，TCP的缓冲区采用的是队列结构。这包括TCP的发送缓冲区和接收缓冲区。数据按照到达的顺序被添加到缓冲区中，并且也是按照这个顺序被处理或发送出去。TCP报文包含序号，TCP会按照序号进行排序，按序号由小到大的入队列。这样就保证了上层拿到的数据是有序的。
当TCP报文中URG标志位为1,则16位紧急指针有效,这表明该报文段携带了紧急数据。紧急指针的存在主要是为了通知接收端存在需要优先处理的数据，紧急指针的数据不用进入队列，但并不直接导致网络层面的优先传输。
16位紧急指针：是一个偏移量，它告诉接收端紧急数据在哪里。

RST

当通信双方三次握手结束后，双方开始正常通信时，其中服务器因为一些原因释放客户的链接。这时客户端不知道，客户端像以前一样向服务器发送请求，服务器在收到请求后，查看建立的链接，发现没有与这个客户端建立链接，就会对这个客户的响应的报文中的6个标志位中RST置1，要求重新建立连接。这时客户端就会将原来的链接释放掉，然后重新在发送三次握手。

确认应答(ACK)机制

本质是确认是否丢包

当我发送的数据，如果对方没有收到，那么我作为发送方，我也得知道对方没收到，如果对方收到了，我要知道我们收到了，没收到我要知道，他没收到。所以对于我们所做的所有工作我们都要有反馈。这一套机制整体叫 可靠性。

TCP将每个字节的数据都进行了编号. 即为序列号.

确认序号X: 就算X-1之前的应答有的没有收到，但是只有收到确认序号X，那证明X-1之前的报文已经全部收到了，下次发请从X编号开始发送。确认应当可以允许少量的ACK应答丢失，更细粒度的确认丢失的原因。

🔎 为什么TCP有 序号 和 确认序号不能将着两个字段合并成一个字段吗？
为什么会有这个问题那，在将客户端中从几字节到几字节的数据发送给服务端，服务端在将确认序号响应给客户端表示收到了数据，在着双方通信时都空着一个字段，不是序号字段就是确认序号字段，如果将这两个字段合并不是就节省了空间吗？但是如果响应只包含确认序号那不是双方的交互效率太低了吗？反而浪费了时间。因此响应不仅可以包含服务端对客户端的响应还可以包含服务端对客户端的请求压缩成请求/响应，这样的方式称为稍带应答，所以TCP要有 序号 和 确认序号两个字段。

超时重传机制

主机A发送数据给B之后, 可能因为网络拥堵等原因, 数据无法到达主机B;
如果主机A在一个特定时间间隔内没有收到B发来的确认应答, 就会进行重发;

数据在没有收到应答时，是不能清除的，以保证超时重传。

但是, 主机A未收到B发来的确认应答, 也可能是因为ACK丢失了;

因此主机B会收到很多重复数据. 那么TCP协议需要能够识别出那些包是重复的包, 并且把重复的丢弃掉. 这时候我们可以利用前面提到的序列号, 就可以很容易做到去重的效果.

那么, 如果超时的时间如何确定?

• 最理想的情况下, 找到一个最小的时间, 保证 “确认应答一定能在这个时间内返回”.
• 但是这个时间的长短, 随着网络环境的不同, 是有差异的.
• 如果超时时间设的太长, 会影响整体的重传效率;
• 如果超时时间设的太短, 有可能会频繁发送重复的包;

TCP为了保证无论在任何环境下都能比较高性能的通信, 因此会动态计算这个最大超时时间.

• Linux中(BSD Unix和Windows也是如此), 超时以500ms为一个单位进行控制, 每次判定超时重发的超时时间都是500ms的整数倍.
• 如果重发一次之后, 仍然得不到应答, 等待 2*500ms 后再进行重传.
• 如果仍然得不到应答, 等待 4*500ms 进行重传. 依次类推, 以指数形式递增.
• 累计到一定的重传次数, TCP认为网络或者对端主机出现异常, 强制关闭连接

连接管理机制

许多客户端，与服务器建立链接，一定在OS服务器内同时存在多个建立好的连接，OS要不要把这些已经建立好的连接管理起来，要管理，就要先描述，在组织。OS内为了管理连接维护的数据结构，创建维护连接是有成本的。
在正常情况下, TCP要经过三次握手建立连接, 四次挥手断开连接

三次握手

最后一个ACK可能会因为一些不可抗拒的因素而导致对方无法收到，此时链接客户端会认为链接建立好了客户端就会进入的ESTABUSHED状态，但服务器会认为链接没建立好，此处就会存在两个结论，第一个，当我们在第三次握手的时候，最后一个报文丢失，其实就是在赌概率。没有人说链接建立的过程必须得成功，也可能失败。那么只要他成功通信就行了，不成功我们要RST要求对方重新建立链接。第二个，链接建立并不一定成功。注意：在正常的网络通信过程最后一个报文丢失的都是小概率事件。

🔎 所以那么我们为什么不是四次握手呢？或者是偶数次握手了？
就是在我们主动建立链接的时候。最后一个报文谁发的，那么他的链接就先建立。而其中如果是奇数次握手，一定是客户端来主动发起最后一个ACK。如果是偶数次握手。一定是服务器端主动发起我们的最后一次握手，你应该发现了最后一个报文，它一定是要在网络当中进行传输，要花时间的，所以如果是奇数次握手。那么它最后一个报文一定是由我们所对应的叫做客后端最后一次发起，偶数次握手，它的最后一个报一定是由服务端主动发起的，奇数次握握手也就直接决定了，那么一定是客户端先把连接建立好。然后我服务器才给你把连接建立好。而偶数次握手，是我的服务器端先建立好链接，此时把这个不确定性就带给了服务器，因为最后一次ACK，那么客户端有没有收到，服务器并不确认。所以那么我们为什么不是四次握手呢？或者是偶数次握手了，那么主要原因是因为那么我们链接握手一定会发生异常，一定有概率。尤其是对于服务器，它一旦面临多个客户端，那么出现链接异常的情况一定是家常便饭的事情。所以链接一旦建立异常，比如说N次握手，我们最不担心N-1次之前的报文丢失，就是因为N-1次之前所有的报文都会有应答，而且链接N次握手并没有完成，双方并没有开始维护这个成本，但如果是偶数次握手呢，那么最后一次我们发送ACK，那么承担链接建立异常的这种成本就可能会嫁接到服务器端。那服务器端是面对的是多个客户端，所以几乎就会导致服务器端维护这种异常链接会成为必然，那么对服务来讲，这就特别不好。

🔎 为什么要三次握手呢？

1. 没有明显的设计漏洞，一但建立的链接出现异常，成本嫁接到客户端，服务的成本较低。
2. 3次握手是检验双方通信，最小次数。TCP建立链接时并不清楚客户端和服务器将怎么通信，所以客户端和我们对应的服务器它必须得先验证双方通信信道是通畅的。因为TCP协议在通讯时是全双工通信，必须得保证双方通信的信道是通畅的。

四次挥手

为什么是四次挥手？
主要的是争得通信双方同意。因为TCP连接是全双工的，可以同时进行数据的双向传输。这意味着连接的关闭需要分别关闭两个方向的数据传输通道，确保数据的完全传输和资源的正确释放，因此需要四个步骤来确保双方都知晓连接的关闭情况且不会丢失数据，其中每两个的步骤就是关闭一个方向的通信。同时四次挥手是关闭双方通信的最少次数。
第二次挥手和第三次挥手不会合并，原因在于这两个步骤各自承担着不同的功能，并且需要独立的确认机制来保证连接的可靠关闭。每个步骤独立确认的原则，这是为了确保连接关闭的可靠性和双方状态的一致性。

注意：客户端和服务端都可以发起断开链接请求，通常主要是客户端发起断开链接请求。

理解TIME_WAIT

TCP协议规定,主动关闭连接的一方要处于TIME_ WAIT状态,等待两个MSL(maximum segment lifetime)的时间后才能回到CLOSED状态.。

理解CLOSE_WAIT

对于服务器上出现大量的 CLOSE_WAIT 状态, 原因就是服务器没有正确的关闭 socket, 导致四次挥手没有正确完成. 这是一个 BUG. 只需要加上对应的 close 即可解决问题。简单的说就是，内存泄漏。每个连接都会占用服务器的维护相应的数据结构，最终就会导致服务器可用资源越来越少。还有对造成文件描述符泄漏以外，可能也会导致连接资源没有完全释放，这其实也是一种内存泄漏的问题。

滑动窗口

可以将发送缓冲区当中的数据分为三部分

• 窗口大小指的是无需等待确认应答而可以继续发送数据的最大值. 上图的窗口大小就是4000个字节(四个段).
• 发送前四个段的时候, 不需要等待任何ACK, 直接发送;
• 收到第一个ACK后, 滑动窗口向后移动, 继续发送第五个段的数据; 依次类推;
• 操作系统内核为了维护这个滑动窗口, 需要开辟发送缓冲区来记录当前还有哪些数据没有应答; 只有确认应答过的数据, 才能从缓冲区删掉;
• 窗口越大, 则网络的吞吐率就越高;

如何实现滑动窗口？
TCP发送缓冲区都看作一个字符数组，而滑动窗口实际就可以看作是两个数组下标限定的一个范围，比如我们用start指向滑动窗口的左侧，end指向的是滑动窗口的右侧，此时在win_start和win_end区间范围内的就可以叫做滑动窗口。

滑动窗口只能向右移动，因为左边的数据已经发送了。滑动窗口只能变大，不是变小。滑动窗口的大小是由对方的TCP报文中16位窗口大小来确定的，所以滑动窗口的大小是浮动的。滑动窗口的大小变成0，表示对方不能在接收数据了。滑动窗口的大小怎么更新，依据对方的接收能力(报文中的窗口大小)来确定。

流量控制

TCP支持根据接收端的处理能力, 来决定发送端的发送速度. 这个机制就叫做流量控制

• 接收端(通信双方可以互为接受端)将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段, 通过ACK端通知发送端;
• 窗口大小字段越大, 说明网络的吞吐量越高;
• 接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端;
• 发送端接受到这个窗口之后, 就会减慢自己的发送速度;
• 如果接收端缓冲区满了, 就会将窗口置为0; 这时发送方不再发送数据, 但是需要定期发送一个窗口探测数据段, 使接收端把窗口大小告诉发送端

双方在第一次通信时如何确定发送数据的多少那？
双方在三次握手期间，已经至少有过一次的请求与响应报头交换了，就可以双方的接收与发送缓冲区的大小，客户端在三次握手建立链接时是不会携带数据的。

一旦发送窗口为0或者接收窗口为0，我们双方就要进行窗口探测和窗口更新来进行尽快重新进行形成共识，然后尽快再发送。窗口探测与窗口更新这两种方案是同时运用的。

拥塞控制

两台主机在网络通信时，出现个别数据包丢包的情况是很正常的，可以通过快重传或超时重发进行数据包补发。如果出现了大量丢包，此时就不能认为是正常现象了，可能是发生网络阻塞了。因为网络上有很多的计算机, 可能当前的网络状态就已经比较拥堵. 在不清楚当前网络状态下, 贸然发送大量的数据,是很有可能引起雪上加霜的。
TCP引入慢启动机制, 先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据。

• 慢启动：开始时，拥塞窗口很小，随着数据包的成功接收，它会指数增长。这个阶段被称为慢启动，因为初始速度较慢，但随后迅速增加。
• 拥塞避免：当拥塞窗口达到一个阈值（sshtresh），进入拥塞避免阶段。在这个阶段，拥塞窗口的增长不再是指数级的，而是线性的，这样可以防止网络过载。
• 乘法减小：如果出现丢包现象（通常由超时或快速重传触发），则认为网络可能已经拥塞。此时，sshtresh被设置为当前的网络拥塞，时阻塞窗口的一半，拥塞窗口重新被设置为一个较小的值（通常是1或2）。这称为乘法减小，因为它将拥塞窗口和sshtresh都减少到原来的一部分
• 主机在进行网络通信时，不断的进行这样的循环

滑动窗口的大小 = min(对端主机的接收能力(16窗口大小)，拥塞串口的大小)。

延迟应答

如果接收数据的主机立刻返回ACK应答, 这时候返回的窗口可能比较小.

• 假设接收端缓冲区为1M. 一次收到了500K的数据; 如果立刻应答, 返回的窗口就是500K;
• 但实际上可能处理端处理的速度很快, 10ms之内就把500K数据从缓冲区消费掉了;
• 在这种情况下, 接收端处理还远没有达到自己的极限, 即使窗口再放大一些, 也能处理过来;
• 如果接收端稍微等一会再应答, 比如等待200ms再应答, 那么这个时候返回的窗口大小就是1M;

一定要记得, 窗口越大, 网络吞吐量就越大, 传输效率就越高. 我们的目标是在保证网络不拥塞的情况下尽量提高传输效率;

不是所有的数据包都可以延迟应答。

• 数量限制：每个N个包就应答一次。
• 时间限制：超过最大延迟时间就应答一次（这个时间不会导致误超时重传）

具体的数量和超时时间, 依操作系统不同也有差异; 一般N为2, 超时时间取200ms。

捎带应答

捎带应答（ Piggybacking ACKs ）是TCP协议中一种优化数据传输效率的方法。该方法利用了这样一个事实：在全双工通信中，双方通常都会有机会既作为发送方又作为接收方。当一端需要发送数据给对方时，可以在该数据包的头部中包含对之前接收到数据的确认信息（ACK），而不是单独发送一个ACK包。这样做可以减少网络中的数据包数量，降低网络拥塞，提高整体的通信效率。

面向字节流

创建一个TCP的socket, 同时在内核中创建一个 发送缓冲区和一个 接收缓冲区;

• 调用write时, 数据会先写入发送缓冲区中;
• 如果发送的字节数太长, 会被拆分成多个TCP的数据包发出;
• 如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去;
• 接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;
• 然后应用程序可以调用read从接收缓冲区拿数据;
• 另一方面, TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可以写数据. 这个概念叫做全双工

由于缓冲区的存在, TCP程序的读和写不需要一一匹配, 例如.

• 写100个字节数据时, 可以调用一次write写100个字节, 也可以调用100次write, 每次写一个字节.
• 读100个字节数据时, 也完全不需要考虑写的时候是怎么写的, 既可以一次read 100个字节, 也可以一次read一个字节, 重复100次.

粘包问题

• 首先要明确, 粘包问题中的 “包” , 是指的应用层的数据包。
• 在TCP的协议头中, 没有如同UDP一样的 “报文长度” 这样的字段, 但是有一个序号这样的字段.。
• 站在传输层的角度, TCP是一个一个报文过来的. 按照序号排好序放在缓冲区中。
• 站在应用层的角度, 看到的只是一串连续的字节数据。
• 那么应用程序看到了这么一连串的字节数据, 就不知道从哪个部分开始到哪个部分, 是一个完整的应用层数据包。

🔎 如何避免TCP粘包问题呢? 归根结底就是一句话, 明确两个包之间的边界。

• 对于定长的包, 保证每次都按固定大小读取即可。
• 对于变长的包, 可以在包头的位置, 约定一个包总长度的字段, 从而就知道了包的结束位置。
• 对于变长的包, 还可以在包和包之间使用明确的分隔符(应用层协议, 是程序猿自己来定的, 只要保证分隔符不和正文冲突即可)。

🔎 UDP是不存在粘包问题。

• 对于UDP, 如果还没有上层交付数据, UDP的报文长度仍然在. 同时, UDP是一个一个把数据交付给应用层. 就有很明确的数据边界。
• 站在应用层的站在应用层的角度, 使用UDP的时候, 要么收到完整的UDP报文, 要么不收. 不会出现"半个"的情况。

TCP异常情况

1. 进程终止
   进程终止操作系统会回收其占用的资源，包括内存、文件描述符等, 仍然可以完成四次挥手. 和正常关闭没有什么区别。
2. 机器重启/关机
   当我们选择重启/关机时，操作系统会先关闭所有进程然后再进行关机或重启，因此机器重启或关机和进程终止的情况是一样的，此时双方操作系统也会正常完成四次挥手，然后释放对应的连接资源。
3. 机器掉电/网线断开

• 接收端认为连接还在, 一旦接收端有写入操作, 接收端发现连接已经不在了, 就会进行reset. 即使没有写入操作, TCP自己也内置了一个保活定时器, 会定期询问对方是否还在. 如果对方不在, 也会把连接释放.
• 如果这时客户端又重新插上网线，如果客户端的链接还在，是可以通信的。如果客户端没有链接了，这时服务器发起请求或响应，客户端就会向服务器发送RST