8

进程和线程有何区别？

15.1 进程与线程 --《程序员面试金典（第 6 版）》P/375

进程和线程彼此关联，但两者有着本质上的区别。

进程可以看作是程序执行时的实例，是一个分配了系统资源（比如 CPU 时间和内存）的独立实体。每个进程都在各自独立的地址空间里执行，一个进程无法访问另一个进程的变量和数据结构。如果一个进程想要访问其他进程的资源，就必须使用进程间通信机制，包括管道、文件、套接字 (socket) 及其他形式。

线程存在于进程中，共享进程的资源（包括它的堆空间）。同一进程里的多个线程将共享同一个堆空间。这跟进程大不相同，一个进程不能直接访问另一个进程的内存。不过，每个线程仍然会有自己的寄存器和栈，而其他线程可以读写堆内存。

线程是进程的某条执行路径。当某个线程修改进程资源时，其他兄弟线程就会立即看到由此产生的变化。

Thread Specific Data

参考：《多线程私有数据 pthread_key_create》

在多线程的环境下，进程内的所有线程共享进程的数据空间。因此全局变量为所有线程共享。在程序设计中有时需要保存线程自己的全局变量，这种特殊的变量仅在线程内部有效。

如常见的 errno ，它返回标准的错误码。errno 不应该是一个局部变量。几乎每个函数都应该可以访问它，但他又不能作为是一个全局变量。否则在一个线程里输出的很可能是另一个线程的出错信息，这个问题可以通过创建线程的私有数据 (Thread Specific Data, TSD) 来解决。在线程内部，私有数据可以被各个函数访问。但他对其他线程是屏蔽的。

线程私有数据采用了一键多值的技术，即一个键对应多个值。访问数据时都是通过键值来访问，好像是对一个变量进行访问，其实是在访问不同的数据。

Websocket

下面的 HTTP 指 1.1 版本。参考：Websocket

WebSocket 是 HTML5 新增的协议，它的目的是在浏览器和服务器之间建立一个不受限的双向通信的通道，比如说，服务器可以在任意时刻发送消息给浏览器。

为什么传统的 HTTP 协议不能做到 WebSocket 实现的功能？这是因为 HTTP 协议是一个 请求－响应协议 ，请求必须先由浏览器发给服务器，服务器才能响应这个请求，再把数据发送给浏览器。换句话说，浏览器不主动请求，服务器是没法主动发数据给浏览器的。这样一来，要在浏览器中搞一个实时聊天，只能用轮询。

半双工/全双工

HTTP 是基于 TCP 的，是双工的。双工的两种模式：半双工（HTTP 1.0/1.1），全双工（HTTP 2.0）。

• 半双工：同一时间内，链接上只能有一方发送数据，另一方接受数据。

  • HTTP 1.0 是短连接模式，每个请求都要建立新的 TCP 连接。

  • HTTP 1.1 是长连接模式，可以多路复用，建立 TCP 连接。

• 全双工：同一时间内，两端都可以发送或接受数据。

HTTP2 / HTTP3 QUIC

【待完善】

TCP 三次握手时，最后一个包丢了会怎样？

【待完善】

TCP

TCP 是一种面向连接的、可靠的全双工传输协议。

参考：再谈 TCP 拥塞控制

TCP 协议中的两个重要算法，**流量控制(Flow Control)和拥塞控制(Congestion Control)**像海尔兄弟一样。

流量控制

In data communications, flow control is the process of managing the rate of data transmission between two nodes to prevent a fast sender from overwhelming a slow receiver.

It provides a mechanism for the receiver to control the transmission speed, so that the receiving node is not overwhelmed with data from transmitting node.

可以看到流量控制是通信双方之间约定数据量的一种机制，具体来说是借助于 TCP 协议的确认 ACK 机制和窗口协议来完成的。

窗口分为固定窗口和可变窗口，可变窗口也就是滑动窗口，简单来说就是通信双方根据接收方的接收情况动态告诉发送端可以发送的数据量，从而实现发送方和接收方的数据收发能力匹配。

这个过程非常容易捕捉，使用 wireshark 在电脑上抓或者 tcpdump 在服务器上抓都可以看到。

可见流量控制是端到端微观层面的数据策略，双方在数据通信的过程中并不关心链路带宽情况，只关心通信双方的接收发送缓冲区的空间大小，可以说是个速率流量匹配策略。

流量控制就像现实生活中物流领域中A和B两个仓库，A往B运送货物时只关心仓库B的剩余空间来调整自己的发货量，而不关心高速是否拥堵。

拥塞控制

拥塞控制的必要性：前面我们提到了微观层面点到点的流量控制，但是我们不由地思考一个问题，只有流量控制够吗？答案是否定的。

我们还需要一个宏观层面的控去避免网络链路的拥堵，否则再好的端到端流量控制算法也面临丢包、乱序、重传问题，只能造成恶性循环。

如何感知拥塞？

TCP 连接的发送方在向对端发送数据的过程中，需要根据当前的网络状况来调整发送速率，所以感知能力很关键。

在 TCP 连接的发送方一般是基于丢包来判断当前网络是否发生拥塞，丢包可以由重传超时 RTO 和重复确认来做判断。

拥塞控制过程详解：我们以典型慢启动、拥塞避免、快速重传、快速恢复四个过程进行阐述。