文章目录
简单的TCP英译汉服务器
我们在上一篇博客中简单实现了一个多执行流的TCP服务器 多执行流服务器
在实现多执行流服务器的时候我们分别完成了多进程和多线程版本
为了进一步优化 我们最后还将线程池引入了我们的服务器当中
此时访问TCP服务器的各个客户端 分别由不同的执行流为其提供服务 因此这些客户端能够同时享受服务器提供的服务
我们当时说过 如果想要修改这个服务器的功能 我们只需要修改其中的handler方法即可 下面我们以简单的英译汉服务器为例 看看更改后我们的TCP服务器能否正常为客户端提供英译汉服务
更改handler方法
我们之前是使用回调函数的方式来处理 当线程池当中的线程从任务队列中拿出一个任务后 会调用该任务对应的Run方法处理该任务
class Handler
{
public:
Handler() = default;
void operator()(int sock)
{
// map three words
unordered_map<string , string> dict;
dict.insert(make_pair("hello" , "nihao"));
dict.insert(make_pair("world" , "shijie"));
dict.insert(make_pair("sort" , "paixu"));
char buff[1024];
string value;
while(true)
{
ssize_t size = read(sock , buff , sizeof(buff) - 1);
if(size > 0)
{
buff[size] = 0;
cout << "sock: " << sock << endl;
string key = buff;
auto it = dict.find(key);
if (it != dict.end())
{
value = it -> second;
}
else
{
value = key;
}
write(sock , value.c_str() , value.size());
}
else if (size == 0)
{
cout << "read close" << endl;
break;
}
else
{
cout << "unknown error " << endl;
break;
}
}
close(sock);
cout << "service end" << endl;
}
};
这里因为汉字在linux系统上显示有点问题 所以我们这里使用汉字拼音来替代了 下面是替代效果
我们可以发现如果我们发送的是字典里面记录过的单词服务器就会回显给我们它的中文拼音
如果发送的不是字典里面记录过的单词就会回显单词本身
地址转换函数
字符串转化整型IP
inet_addr函数的函数原型如下：
in_addr_t inet_addr(const char *cp);
参数说明：
- cp：待转换的字符串IP。
返回值说明：
- 如果输入的地址有效，则返回转换后的整数IP；如果输入的地址无效，则返回INADDR_NONE（通常为-1）
整数IP转化字符串
inet_ntoa函数的函数原型如下：
char *inet_ntoa(struct in_addr in);
参数说明：
- in：待转换的整数IP。
返回值说明：
- 返回转换后的字符串IP。
绑定失败问题
绑定端口失败主要是由三个问题引起的
当我们在测试网络代码时 先将服务端绑定8081端口运行 然后运行客户端 并让客户端连接当前服务器
这也验证了一个端口只能绑定一个进程的规则
当我们在测试网络代码时 先将服务端绑定8081端口运行 然后运行客户端 并让客户端连接当前服务器
此时在有客户端连接服务端的情况下 如果直接将服务端关闭 此时服务端要想再次绑定8081号端口运行 就可能会绑定失败
我们自己编写的服务器代码在绑定端口号时 尽量不要绑定1024以下的端口号 一般云服务器只能绑定1024及其往上的端口号 因为1024以下的端口已经约定俗成被其他一些比较成熟的服务所使用了 如果我们绑定1024以下的端口号 那么会绑定失败
TCP协议通讯流程
通讯流程总览
下图是基于TCP协议的客户端/服务器程序的一般流程：
下面我们结合TCP协议的通信流程 来初步认识一下三次握手和四次挥手 以及建立连接和断开连接与各个网络接口之间的对应关系
三次握手
当服务器完成套接字创建、绑定以及监听的初始化动作之后，就可以调用accept函数阻塞等待客户端发起请求连接了
服务器初始化：
- 调用socket，创建文件描述符。
- 调用bind，将当前的文件描述符和IP/PORT绑定在一起，如果这个端口已经被其他进程占用了，就会bind失败。
- 调用listen，声明当前这个文件描述符作为一个服务器的文件描述符，为后面的accept做好准备。
- 调用accept，并阻塞，等待客户端连接到来。
而客户端在完成套接字创建后，就会在合适的时候通过connect函数向服务器发起连接请求，而客户端在connect的时候本质是通过某种方式向服务器三次握手，因此connect的作用实际就是触发三次握手。
建立连接的过程：
- 调用socket，创建文件描述符。
- 调用connect，向服务器发起连接请求。
- connect会发出SYN段并阻塞等待服务器应答（第一次）。
- 服务器收到客户端的SYN，会应答一个SYN-ACK段表示“同意建立连接”（第二次）。
- 客户端收到SYN-ACK后会从connect返回，同时应答一个ACK段（第三次）
这个建立连接的过程，通常称为三次握手。
需要注意的是，连接并不是立马建立成功的，由于TCP属于传输层协议，因此在建立连接时双方的操作系统会自主进行三次协商，最后连接才会建立成功。
数据传输的过程
连接一旦建立成功并且被accept获取上来后，此时客户端和服务器就可以进行数据交互了。需要注意的是，连接建立和连接被拿到用户层是两码事，accept函数实际不参与三次握手这个过程，因为三次握手本身就是底层TCP所做的工作。accept要做的只是将底层已经建立好的连接拿到用户层，如果底层没有建立好的连接，那么accept函数就会阻塞住直到有建立好的连接。
而双方在进行数据交互时使用的实际就是read和write，其中write就叫做写数据，read就叫做读数据。write的任务就是把用户数据拷贝到操作系统，而拷贝过去的数据何时发以及发多少，就是由TCP决定的。而read的任务就是把数据从内核读到用户。
数据传输的过程：
- 建立连接后，TCP协议提供全双工的通信服务，所谓全双工的意思是，在同一条连接中，同一时刻，通信双方可以同时写数据，相对的概念叫做半双工，同一条连接在同一时刻，只能由一方来写数据。
- 服务器从accept返回后立刻调用read，读socket就像读管道一样，如果没有数据到达就阻塞等待。
- 这时客户端调用write发送请求给服务器，服务器收到后从read返回，对客户端的请求进行处理，在此期间客户端调用read阻塞等待服务器端应答。
- 服务器调用write将处理的结果发回给客户端，再次调用read阻塞等待下一条请求。
- 客户端收到后从read返回，发送下一条请求，如此循环下去。
四次挥手的过程
当双方通信结束之后，需要通过四次挥手的方案使双方断开连接，当客户端调用close关闭连接后，服务器最终也会关闭对应的连接。而其中一次close就对应两次挥手，因此一对close最终对应的就是四次挥手。
断开连接的过程：
- 如果客户端没有更多的请求了，就调用close关闭连接，客户端会向服务器发送FIN段（第一次）。
- 此时服务器收到FIN后，会回应一个ACK，同时read会返回0（第二次）。
- read返回之后，服务器就知道客户端关闭了连接，也调用close关闭连接，这个时候服务器会向客户端发送一个FIN（第三次）。
- 客户端收到FIN，再返回一个ACK给服务器（第四次）。
这个断开连接的过程，通常称为四次挥手。
在学习socket API时要注意应用程序和TCP协议是如何交互的：
- 应用程序调用某个socket函数时TCP协议层完成什么动作，比如调用connect会发出SYN段。
- 应用程序如何知道TCP协议层的状态变化，比如从某个阻塞的socket函数返回就表明TCP协议收到了某些段，再比如read返回0就表明收到了FIN段。
建立连接本质上是为了保证通信双方都有专属的连接，这样我们就可以加入很多的传输策略，从而保证数据传输的可靠性。但如果双方通信结束后不断开对应的连接，那么系统的资源就会越来越少。
因为服务器是会收到大量连接的，操作系统必须要对这些连接进行管理，在管理连接时我们需要“先描述再组织”。因此当一个连接建立后，在服务端就会为该连接维护对应的数据结构，并且会将这些连接的数据结构组织起来，此时操作系统对连接的管理就变成了对链表的增删查改。
如果一个连接建立后不断开，那么操作系统就需要一直为其维护对应的数据结构，而维护这个数据结构是需要花费时间和空间的，因此当双方通信结束后就应该将这个连接断开，避免系统资源的浪费，这其实就是TCP比UDP更复杂的原因之一，因为TCP需要对连接进行管理。
TCP/UDP
- 可靠传输 vs 不可靠传输
- 有连接 vs 无连接
- 字节流 vs 数据报