TCP/IP协议栈#

介绍一下$TCP/IP$所属的$TCP/IP$协议栈（$Stack$, 层）。

由图可以看出，$TCP/IP$协议栈分为四层。也就是说对于“基于互联网的有效数据传输”这个命题，并非通过一个庞大的协议解决问题，而是化整为零，通过层次化方案————$TCP/IP$协议栈解决。
各层可能通过操作系统等软件实现，也可能通过类似$NIC$的硬件设备实现。

NOTE

OSI 7 Layer（层）
数据通信中使用的协议栈分为7层，一般来说掌握本书分的4层也足够了。

TCP/IP协议的诞生背景#

计算机网络问题并非仅凭软件就能解决，还需要构建硬件系统，软件上实现算法，因此我们将“通过因特网完成有效数据传输”问题按照不同领域划分为小问题后，出现了多种协议，它们通过层级结构建立了紧密联系。
开放式系统（Open System）
设计开放式系统是为了标准化操作。标准本身就在于对外公开，引导更多人遵守规范，以多个标准为依据设计的系统称为开放式系统。（$TCP/IP$协议栈也属于其中之一）举例来说就是，不同的路由器和网卡通过这样标准化的设计，都可以实现数据互通，不会因为型号不同而导致数据无法传输。
链路层
链路层是物理链接领域标准化的结果，专门定义$LAN、WAN、MAN$等网络标准。若两台主机通过网络进行数据交换，就需要图中所示的物理连接，链路层就负责这些标准。

TCP服务器端#

函数调用顺序
绝大部分$TCP$服务器端都按照如下顺序调用函数：

前两步已经在之前的章节介绍过：调用$socket$创建套接字，再初始化地址信息结构体并通过$bind$为套接字分配$IP$和端口。接下来还需要让套接字进入等待状态并受理客户端的连接请求。
进入等待连接请求状态
调用$bind$分配地址后，通过$listen$使套接字进入等待连接请求状态。只有服务器端调用$listen$后，客户端才能正常调用$connect$发起连接请求。

1
int listen(int sock, int backlog);

$sock$是要进入等待状态的套接字文件描述符，调用成功后该套接字就成为服务器端套接字，也称监听套接字。$backlog$决定连接请求等待队列的长度，例如传入$5$表示最多允许$5$个连接请求进入队列等待处理。函数成功时返回$0$，失败时返回$-1$。
客户端的连接请求本身也是通过网络到达的数据。监听套接字就像门卫，负责接收这些请求并将它们放入等待队列，但不负责之后与客户端进行实际的数据交换。
受理客户端连接请求
服务器端通过$accept$依次受理等待队列中的连接请求：

1
int accept(int sock, struct sockaddr *addr, socklen_t *addrlen);

$sock$是监听套接字，$addr$和$addrlen$用于保存发起请求的客户端地址信息。调用成功时，$accept$会自动创建一个与该客户端连接的套接字，并返回它的文件描述符；后续的$read、write$和$close$都针对这个新套接字，而监听套接字继续负责接收其他连接请求。
如果等待队列为空，$accept$会进入阻塞（$blocking$）状态，直到出现新的客户端连接请求才返回。

TCP客户端#

函数调用顺序
客户端的实现比服务器端简单，主要过程是创建套接字、请求连接、交换数据并关闭连接。

请求连接通过$connect$函数完成：

1
int connect(int sock, struct sockaddr *servaddr, socklen_t addrlen);

$sock$是客户端套接字，$servaddr$保存目标服务器端的地址信息，$addrlen$是该地址结构体的长度。服务器端将连接请求记录到等待队列，或连接因断网等异常而中断时，$connect$才会返回。这里的“接收连接请求”不等同于服务器端已经调用$accept$，所以$connect$返回后，服务器端不一定已经开始与该客户端交换数据。
客户端没有像服务器端一样显式调用$bind$，但并非无需地址。调用$connect$时，操作系统会在内核中自动分配客户端地址：$IP$使用本机$IP$，端口则自动选择。
服务器端与客户端的函数调用关系
服务器端依次调用$socket、bind、listen$进入等待状态，客户端随后调用$connect$发起连接请求，服务器端再通过$accept$取得用于数据交换的新套接字。服务器端可以先调用$accept$，此时它会阻塞并等待客户端调用$connect$。

实现迭代服务器端#

此前的$Hello World$服务器端处理完一个客户端的连接请求就退出，没有真正利用连接请求等待队列。若要继续服务后续客户端，最简单的办法就是用循环反复调用$accept$。
服务器端函数调用顺序：

迭代回声服务器端/客户端#

程序的基本运行方式：

1. 服务器端在同一时刻只与一个客户端相连，并提供回声服务。
2. 服务器端依次向$5$个客户端提供服务并退出。
3. 客户端接收用户输入的字符串并发送到服务端。
4. 服务端将接收的字符串数据传回客户端，即“回声”。
5. 服务端与客户端之间的字符串回声一直执行到客户端输入$Q$为止。
   这里本书给出了回声服务器端和客户端的完整源码，与此前第一、二章的区别主要在于服务器端循环调用$accept$，依次为多个客户端提供服务。其核心结构如下：

1
for (i = 0; i < 5; i++)
2
{
3
    clnt_sock = accept(serv_sock, (struct sockaddr *)&clnt_adr,
4
                       &clnt_adr_sz);
5
    while ((str_len = read(clnt_sock, message, BUF_SIZE)) != 0)
6
        write(clnt_sock, message, str_len);
7
    close(clnt_sock);
8
}
9
close(serv_sock);

客户端输入$Q$后调用$close$关闭套接字，同时向服务器端传递$EOF$。服务器端的$read$因此返回$0$，结束当前回声循环并关闭对应的连接套接字，随后继续调用$accept$等待下一个客户端。

回声客户端存在的问题#

对应$echo\_client.c$的第45~48行代码。

1
write(sock, message, strlen(message));
2
str_len = read(sock, message, BUF_SIZE - 1);
3
message[str_len] = 0;
4
printf("Message from server: %s", message);

这段代码错误地假设每次调用$read、write$都会以一个字符串为单位完成实际的$I/O$。因为$TCP$不存在数据边界，多次$write$发送的字符串可能被服务器端一次$read$接收；一个较长字符串也可能被拆成多个数据包，客户端在全部数据到达前就调用$read$，因而只能读取其中一部分。
示例之所以能正常运行，只是因为传输的数据较小，而且通常在同一台或相邻的计算机上测试，并不代表这种写法始终可靠。这个问题会在第五章解决。

定义应用层协议#

回声客户端知道要接收的数据长度，但大部分程序无法提前得知。此时就需要定义应用层协议，通过规则表示数据边界，或提前告知对方数据大小。此前“收到$Q$就终止连接”也是应用层协议的一部分。
书中通过计算器服务器端/客户端演示协议的设计，客户端发送多个整数和一个运算符，服务器端完成加、减、乘运算后返回结果。协议如下：

1. 客户端连接服务器端后，先以$1$字节整数传递操作数个数。
2. 每个操作数占$4$字节。
3. 所有操作数之后传递$1$字节运算符，只能是$+、-、*$之一。
4. 服务器端以$4$字节整数返回运算结果。
5. 客户端收到运算结果后终止连接。
   所以客户端发送的数据可以表示为：
   [操作数个数：1字节][操作数：4字节 × n][运算符：1字节]
   因为同一数组中需要保存多种数据类型，示例将发送缓冲声明为$char$数组，并通过指针转换将$int$型操作数写入其中。客户端根据操作数个数计算发送长度：

1
write(sock, opmsg, opnd_cnt * OPSZ + 2);
2
read(sock, &result, RLT_SIZE);

服务器端先读取$1$字节的操作数个数，再按照协议循环读取剩余的操作数与运算符，计算完成后将$4$字节结果传回。可以发现，应用层协议一旦确定，程序的收发顺序、每次需要读取的长度也就确定了。

TCP套接字中的I/O缓冲#

$write$调用后并非立即将数据交给对方程序，而是先把数据移入本套接字的输出缓冲；$read$则从本套接字的输入缓冲读取数据。输出缓冲中的数据会在合适的时机传入对方的输入缓冲，因此一次写入的数据可以分多次读取。

1. 每个$TCP$套接字都有各自独立的输入缓冲和输出缓冲。
2. $I/O$缓冲在创建套接字时自动生成。
3. 关闭套接字后，输出缓冲中遗留的数据仍会继续传递。
4. 关闭套接字会丢失输入缓冲中尚未读取的数据。
   如果接收方输入缓冲只剩$50$字节空间，发送方不会强行传递$100$字节数据。$TCP$通过滑动窗口协议（$Sliding Window$）告知对方自己还能接收多少数据，接收方读取数据并腾出空间后再更新窗口大小，因此不会因为输入缓冲溢出而丢失数据。

NOTE

$write$和$send$在数据移入输出缓冲后就会返回，并不等待对方主机完成接收。但$TCP$会负责继续传输输出缓冲中的数据，因此从协议保证的角度可以说数据传输已经完成。

TCP内部工作原理1：与对方套接字建立连接#

$TCP$套接字以全双工（$Full-duplex$）方式工作，连接建立后双方都能发送和接收数据。正式交换数据前，需要通过三次握手（$Three-way handshaking$）确认双方均已就绪。

TCP内部工作原理2：与对方主机交换数据#

三次握手完成后开始正式收发数据。假设主机$A$发送$SEQ$为$1200$的$100$字节数据，主机$B$接收后返回$ACK 1301$。书中将确认号的关系表示为：ACK号 = SEQ号 + 传递的字节数 + 1

TCP内部工作原理3：断开与套接字的连接#

若一方直接断开连接，可能导致对方尚未发送的数据无法传输，因此$TCP$断开连接也需要双方协商。双方各发送一次$FIN$并分别确认，整个过程称为四次握手（$Four-way handshaking$）。