计算机网络常见面试题

梳理计算机网络相关的面试题，相关知识结构主要参考谢希仁老师的《计算机网络（第五版）》一书，并整理互联网上常见面试题。

计算机网络性能指标

性能指标从不同的方面来度量计算机网络的性能。下面介绍常用的七个性能指标。

1、速率

计算机发出电信号都是数字形式的。比特(bit)是计算机中数据量的单位。英文字bit来源于binary digit，表示"一个二进制数字"，因此一个比特就是二进制中的一个1或0。网络技术中的速率指的是连接在计算机网络上的主机在数字信道上传送数据的速率，它也称为比特率。速率是计算机网络中最重要的一个性能指标。速率的单位是b/s(比特每秒)，有时也写成bps(bit per second)。当速率较高时，可以用kb/s、Mb/s、Gb/s、Tb/s。现在人们常用更简单的且不严格的记法来描述网络的速率，如100M以太网，而省略了单位b/s。

2、带宽

带宽(Bandwidth)有以下两种不同的意义：
(1) 带宽本身是指某个信号具有的频带宽度。信号的带宽是指该信号所包含的各种不同频率成份所占据的频率范围。这种意义的带宽的单位是赫兹(如300Hz)。在过去的一段时间，通信的主干线路传送的是模拟信号(即连续变化的信号)。因此，表示通信线路允许通过的信号频带范围就成为线路的带宽(或通频带)。
(2) 在计算机网络中，带宽用来表示网络的通信线路所能传达数据的能力。因此网络带宽表示在单位时间内从网络中的某一个点到另一个点所能通过的"最高数据率"。这个意义的带宽的单位是"比特每秒"，记为b/s。在这种单位的前面也常常加上千(k)、兆(M)、吉特(G)等倍数。

3、吞吐量

吞吐量(Throughput)表示在单位时间内通过某个网络(或信道、接口)的数据量。吞吐量更经常地用于对现实世界中的网络的一种测量，以便知道实际上到底有多少数据量能够通过网络。显然，吞吐量受网络的带宽或网路的额定速率的限制。例如，对于一个100Mb/s的以太网，其额定速率是100Mb/s，那么这个数值也是该以太网的吞吐量的决定上限值。

4、时延

时延(delay或latency)是指数据(一个报文或分组、甚至比特)从网络的一段传送到另一端所需要的时间。时延是一个很重要的性能指标，它有时也称为延迟或迟延。需要注意的是，网络中的时延是由以下几个不同的部分组成的：
(1) 发送时延(transmission delay)， 是主机或路由器发送数据帧所需要的时间，也就是从发送数据帧的第一个比特算起，到该帧的最后一个比特发送完毕所需的时间。因此发送时延也叫做传输时延，发送时延的计算公式是：
$$发送时延=数据帧长度(b)/信道带宽(b/s)$$
由此可见，发送时延并不是固定不变，而是与发送的数据帧的长度成正比，与信道带宽成反比。
(2) 传播时延(propagation delay)，是电磁波在信道中传播一定的距离需要花费的时间。传播时延的计算公式是：
$$传播时延=信道长度(m)/电磁波在信道上的传播速率(m/s)$$
电磁波在空气中的传播速度是光速，即$3.0\ast 10^{8}m/s$。电磁波在网络传输媒体中的传播速率比在空气中要低一些，如铜线中的传播速率约为$2.3\ast 10^{8}m/s$，在光纤中的传播速率约为$2.0\ast 10^{8}m/s$。
(3) 处理时延，主机或路由器在收到分组时要花费一定的时间进行处理，如分析分组的首部、从分组中提取数据部分、进行差错校验或查找适当的路由等等，这就产生了处理时延。
(4) 排队时延，分组在经过网络传输时，要经过许多的路由器。但分组在进入路由器后要先在输入队列中排队等待处理。在路由器确认了转发接口后，还要在输出队列中排队等待转发。这就产生了排队时延。排队时延的长短往往取决于网络当时的通信量。当网络的通信量很大时会发生队列溢出，使分组丢失，这相当于排队时延无穷大。

5、时延带宽积

把网络性能的两个度量–传播时延和带宽相乘，就得到另一个很有用的度量：传播时延带宽积，即
时延带宽积 = 传播时延 * 带宽
时延带宽积表示链路可容纳的数据量。对于一条正在传送数据的链路，只有在代表链路的管道中都充满比特时，该链路才得到充分的利用。

6、往返时间RTT

在计算机网络中，往返时间RTT(Round-Trip Time)也是一个重要的性能指标，它表示从发送方发送数据开始，到发送方收到来自接收方的确认(接收方收到数据后便立即发送确认)，总共经历的时间。在互联网中，往返时间还包括各中间结点的处理时延、排队时延以及转发数据时的发送时延。
显然，往返时间与所发送的分组长度有关。发送很长的数据块的往返时间，应当比发送很短的数据块的往返时间要多些。
当使用卫星通信时，往返时间RTT相对较长，是很重要的一个性能指标。

7、利用率

利用率有信道利用率和网络利用率两种。信道利用率指出某信道有百分之几的时间是被利用的(有数据通过)。完全空闲的信道的利用率是零。网络利用率则是全网络的信道利用率的加权平均值。信道利用率并非越高越好。这是因为，根据排队论的理论，当某信道的利用率增大时，该信道引起的时延也就迅速增加。当网络的通信量很少时，网络产生的时延并不大。但在网络通信量不断增大的情况下，由于分组在网络结点(路由器或交换机)进行处理时，需要排队等候，因此网络引起的时延就会增大。
如果令$D_0$表示网络空闲时的时延，$D$表示网络当前的时延，那么在适当的假定条件下，可以用下面的公式表示$D$、$D_0$和利用率$U$之间的关系：
$$D=D_0/(1-U)$$
这里的$U$是网络的利用率，数值在0到1之间。当网络的利用率达到其容量的$1/2$时，时延就要加倍。当网络的利用率接近最大值$1$时，网络的时延就趋于无穷大。也就是说，信道或网络利用率过高时，就会产生非常大的时延。

计算机网络体系结构

计算机网络的各层及其协议的集合，称为网络的体系结构(Architecture)。换句话说，计算机网络的体系结构是这个计算机网络及其构件所应完成的功能的精确定义，是计算机网络中的层次、各层协议及层间接口的集合。

计算机网络体系结构发展简述

相互通信的两个计算机系统必须高度协调工作才能保证通信，而这种"协调"是相当复杂的。为了设计这样复杂的计算机网络，早在最初的ARPANET设计时，就提出了分层的方法。"分层"可将庞大而复杂的问题，转化为若干个较小的局部问题，而这些较小的局部问题就比较易于研究和处理。
1974年，美国的IBM公司宣布了系统网络体系架构(System Network Architecture)。这个著名的网络标准就是分层的方法制定的。不久之后，其他一些公司也相继推出自己公司的具有不同名称的体系结构。
不同的网络体系结构出现后，使用同一个公司生产的各种设备都能够很容易地互联。这种情况显然有利于一个公司垄断市场，但是对于其他公司，如果使用了不同的网络体系结构，则很难相互联通。
全球经济的发展使得不同网络体系结构的用户迫切要求能够互相交换信息。为了使不同体系结构的计算机网络互联互通，国际标准化组织ISO于1977年成立了专门的机构研究该问题。不久，它们就提出一个试图使各种计算机在全世界范围内互联成网的标准框架，即著名的开放系统互连基本参考模型 OSI/RM(Open Systems Interconnection Reference Model)，简称OSI。"开放"是指非独家垄断的。因此只要遵循OSI标准，一个系统就可以和位于世界上任何地方的、也遵循这同一标准的其他任何系统进行通信。"系统"是指在现实的系统中与互连有关的各个部分。在1983年形成了开放系统互连基本参考模型的正式文件，即著名的ISO 7498国际标准，也就是所谓的七层协议的体系结构。
OSI试图达到一种理想境界，即全世界的计算机网络都遵循这个统一的标准，因而全世界的计算机将能够很方便地进行互连和交换数据。在20世纪80年代，OSI获得了很多大公司和一些国家的支持。然而，到了20世界90年代初，虽然整套的OSI国际标准已经制定出来了，但由于因特网已抢先在全世界覆盖了相当大的范围，而此时却几乎找不到有什么厂家生产出符合OSI标准的商用产品。因此：OSI只获得了一些理论研究的成果，但在市场化方面OSI则事与愿违地失败了。OSI失败的原因可以归纳为：
(1) OSI的专家缺少实际经验，他们在完成OSI标准时缺乏商业驱动力；
(2) OSI的协议实现起来过分复杂，二期运行效率很低；
(3) OSI标准的制定时间太长，因而使得按OSI标准生产的设备无法及时进入市场；
(4) OSI的层次划分不太合理，有些功能在多个层次中重复出现。
现今规模最大的、覆盖全世界的因特网没有采用法律上的国际标准OSI，而是非国际标准TCP/IP。这样，TCP/IP成为事实上的国际标准。
在计算机网络中要做到有条不紊地交换数据，就必须遵守一些事先约定好的规则。这些规则明确规定了所交换的数据的格式以及有关的同步问题。这里所说的同步是指在一定的条件下应当发生什么事情，因而同步含有时序的含义。这些为进行网络中的数据交换而建立的规则、标准或约定称为网络协议(Network Protocol)。更进一步，网络协议主要由以下三个要素组成：
(1) 语法，即数据与控制信息的结构或格式；
(2) 语义，即需要发出何种控制的信息，完成何种动作以及做出何种响应；
(3) 同步，即事件实现顺序的详细说明。
由此可见，网络协议是计算机网络的不可缺少的组成部分。

OSI 体系结构

国际标准化组织（ISO）提出的网络体系结构模型，称为开放系统互连参考模型（OSI/RM），简称为OSI参考模型。OSI共有7层，自下而上依次为物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。低三层称为通信子网，它是为了联网而附加的通信设备，完成数据的传输功能；高三层称为资源子网，它相当于计算机系统，完成数据的处理功能；传输层承上启下。OSI层次结构如下图所示：

OSI的物理层

物理层是参考模型的最低层。该层是网络通信的数据传输介质，由连接不同结点的电缆与设备共同构成。主要跟功能是：利用传输介质为数据链路层提供物理连接，负责处理数据传输并监控数据出错率，以便数据流的透明传输。物理层的传输单位是比特，物理层主要定义数据终端设备（DTE）和数据通信设备（DCE）的物理与逻辑连接方法，所以物理层协议也称物理接口标准。
注意：传输信息所利用的一些物理媒体， 如双绞线、光缆、无线信道等，并不在物理层协议之内，而在物理层协议下面。因此有人把物理媒体当作第0层。

OSI的数据链路层

数据链路层是参考模型的第二层。主要功能是：在物理层提供的服务基础上，在通信的实体间建立数据链路连接，实现对MAC地址的访问。数据链路层传输的数据单位是帧，并采用差错控制与流量控制方法，使有差错的物理线路变成无差错的数据链路。数据链路层屏蔽传输介质的物理特征，使数据可靠传送。内容包括介质访问控制、连接控制、顺序控制、流量控制、差错控制和仲裁协议等。

OSI的网络层

网络层是参考模型的第三层。主要功能是：为数据在节点之间传输创建逻辑链路，通过路由选择算法为分组通过通信子网选择最适当的路径，以及实现拥塞控制、网络互连等功能。网络层的传输单位是数据报。关键问题是对分组进行路由选择，实现流量控制、拥塞控制、差错控制和网际互连等功能。

OSI的传输层

传输层是参考模型的第四层。主要功能是：向用户提供可靠地端到端传输服务，处理数据包错误、数据包次序，以及其他一些关键传输问题。传输层的传输单位是报文段（TCP）或用户数据报（UDP）。传输层向高层屏蔽了下层数据通信的细节。
如果说数据链路层提供的是点到点的通信，传输层提供的是端到端的通信。通俗地说，点到点可以理解为主机到主机之间的通信，一个点是指一个硬件地址或IP地址，网络中参与通信的主机是通过硬件地址或IP地址标识的；端到端的通信是指运行在不同主机内的两个进程之间的通信，一个进程由一个端口来标识，所以称端到端通信。

OSI的会话层

会话层是参考模型的第五层。主要功能是：维护不同主机上的各个进程之间进行会话。会话层利用传输层提供的端到端的服务，向表示层提供它的增值服务。这种服务主要为表示层实体或用户进程建立连接并在连接上有序地传输数据，这就是会话，也称建立同步(SYN)。
会话层负责管理主机间的会话进程，包括建立、管理及终止进程间的会话。会话层可以使用校验点使通信会话在通信失效时从校验点继续恢复通信，实现数据同步。

OSI的表示层

表示层是参考模型的第六层。主要功能是：用于处理在两个通信系统中交换信息的表示方法，主要包括数据格式变换、数据加密与解密、数据压缩与恢复等功能。不同机器采用的编码和表示方法不同，使用的数据结构也不同。为了使不同表示方法的数据和信息之间能互相交换，表示层采用抽象的标准方法定义数据结构，并采用标准的编码形式。

OSI的应用层

应用层是参考模型的最高层，是用户与网络的界面。主要功能是：为应用软件提供了很多服务，比如文件服务器、数据库服务、电子邮件与其他网络软件服务。应用层可以看成面向用户的程序或服务，包括系统程序和用户程序，如万维网的HTTP、文件传送的FTP、域名访问的DNS、电子邮件的SMTP等。

TCP/IP 体系结构

ARPA在研究ARPAnet时提出了TCP/IP模型，模型从低到高依次为网络接口层(对应OSI参考模型中的物理层和数据链路层)、网际层、传输层和应用层(对应OSI参考模型中的会话层、表示层和应用层)。TCP/IP 由于得到广泛应用，已成为事实上的国际标准。TCP/IP层次结构如下图所示：

TCP/IP的网络接口层

网络接口层，通常包括操作系统中的设备驱动程序和计算机中对应的网络接口卡。它们一起处理与底层传输媒介的物理接口细节。
在TCP/IP协议族中，网络接口层主要为上层（网络层）提供服务。具体地，（1）为IP模块发送和接收IP数据报；（2）为ARP模块发送ARP请求和接收ARP应答；（3）为RARP发送RARP请求和接收RARP应答。
TCP/IP支持多种不同的网络接口层协议，这取决于网络所使用的硬件，如以太网、令牌环网、FDDI（光纤分布式数据接口）及RS-232串行线路等。对应的协议有：以太网链路层协议，串行接口链路层协议（SLIP和PPP）等。

TCP/IP的网际层

网际层，也称网络层、互联网层，处理分组在网络中的活动，如分组的选路。在TCP/IP协议族中，网络层协议包括IP协议（网际协议），ICMP协议（Internet互联网控制报文协议），以及IGMP协议（Internet组管理协议）等。
IP协议是TCP/IP协议族中最为核心的协议。所有的TCP、UDP、ICMP及IGMP数据都以IP数据报格式传输。IP协议提供不可靠、无连接的数据报传送服务。
不可靠（unreliable）是指它不能保证IP数据报能成功地到达目的地。IP仅提供最好的传输服务。如果发生某种错误时，如某个路由器暂时用完了缓冲区，IP有一个简单的错误处理算法：丢弃该数据报，然后发送ICMP消息报给信源端。任何要求的可靠性必须由上层来提供（如TCP）。
无连接（connectionless）是指IP并不维护任何关于后续数据报的状态信息。每个数据报的处理是相互独立的。这也说明，IP数据报可以不按发送顺序接收。如果一信源向相同的信宿发送两个连续的数据报（先是A，然后是B），每个数据报都是独立地进行路由选择，可能选择不同的路线，因此B可能在A到达之前先到达。

TCP/IP的运输层

运输层，也称传输层，主要为两台主机上的应用程序提供端到端的通信。在TCP/IP协议族中，主要有两个互不相同的传输协议：TCP（传输控制协议，可靠通信）和UDP（用户数据报协议，不可靠通信）。
运输层面向进程，为进程之间提供端到端的逻辑通信。运输层向高层用户屏蔽了下面网络核心的细节，它使进程好像在两个运输层实体间有一条端到端的逻辑通信信道。

TCP/IP的应用层

应用层负责处理特定的应用程序细节。几乎各种不同的TCP/IP实现都会提供下面这些通用的应用程序：(1) Telnet 远程登录；(2) FTP 文件传输协议；(3) SMTP 简单邮件传送协议；(4) SNMP 简单网络管理协议。

OSI 体系结构和TCP/IP 体系结构对比

OSI体系结构和TCP/IP体系结构都是用于描述所有网络通信的概念模型，对比OSI模型和TCP/IP模型可以发现，TCP/IP 的应用层类似于 OSI 的 应用层、表示层、会话层的组合。TCP/IP 的运输层包含 OSI 传输层的职责。TCP/IP 的网际层类似于OSI的网络层。TCP/IP的网络接口层则包含 OSI 的数据链路层和物理层。图示表示如下：

下面OSI体系结构和TCP/IP体系结构的对比表格：

OSI	TCP/IP	Protocol	Data Unit	功能	地址
应用层(Application)	应用层	HTTP，TFTP，FTP，NFS，WAIS，SMTP	数据(data)	应用程序与协议	应用进程
表示层(Presentation)	应用层	Telnet，Rlogin，SNMP，Gopher	数据(data)	数据加解密	应用进程
会话层(Session)	应用层	SMTP，DNS	数据(data)	会话的开始、恢复、释放、同步	应用进程
传输层(Transport)	运输层	TCP，UDP	报文/数据段(segment)	端到端的可靠、透明传输，保证数据完整性	端口号
网络层(Network)	网际层	IP，ICMP，ARP，RARP，AKP，UUCP	数据包(packet)/分组	服务选择、路径选择、多路复用(如何选择发送地址、发送方式)等	IP地址
数据链路层(Data Link)	网络接口层	FDDI， Ethernet，Arpanet，PDN，SLIP，PPP	帧(frame)	差错控制、流量控制等	MAC地址
物理层(Physical)	网络接口层	IEEE 802.1A，IEEE 802.2 to IEEE 802.11	比特(bit)	光纤、电缆、双绞线 等	比特

网络接口层

TCP/IP体系结构的网络接口层，对应OSI体系结构的物理层和数据链路层。包括操作系统中的设备驱动程序和计算机中对应的网络接口卡。它们一起处理与底层传输媒介的物理接口细节。
TCP/IP的网络接口层支持多种不同的网络接口层协议，这取决于网络所使用的硬件，如以太网、令牌环网、FDDI（光纤分布式数据接口）及RS-232串行线路等。对应的协议有：以太网链路层协议，串行接口链路层协议（SLIP和PPP）等。

PPP协议

PPP（Point-to-Point Protocol）协议，直译为点对点协议，是目前使用最广泛的点对点数据链路层协议，主要用于计算机与ISP的通信，也广泛应用于广域网路由器之间的专用线路。
注意，PPP和PPPoE是两种不同的协议。
PPP 是一种用于在两个点之间进行通信的协议，常用于 dial-up 网络和 VPN 连接。PPP 协议提供了多种功能，包括身份验证、数据压缩和加密等，但是它不提供路由功能。
PPPoE 则是一种在以太网上运行 PPP 的协议。它使用了以太网帧来封装 PPP 数据包，并使用一种特殊的服务器/客户端模型来管理 PPP 连接。PPPoE 常用于 ADSL、光纤宽带等拨号上网方式，也可以用于小区宽带网络中。
因此，PPPoE 可以看作是在以太网上运行 PPP 的一种方式，而 PPP 则是一种通用的协议，不仅可以在以太网上运行，也可以在其他类型的网络上运行。

MAC地址

硬件地址又称为物理地址，或MAC地址，是硬件设备的唯一标志。

网际层

IP协议

IP协议是TCP/IP中最为核心的协议。所有的TCP、UDP、ICMP及IGMP数据都以IP数据报格式传输。IP协议提供不可靠、无连接的数据报传送服务。
不可靠（unreliable）是指它不能保证IP数据报能成功地到达目的地。IP仅提供最好的传输服务。如果发生某种错误时，如某个路由器暂时用完了缓冲区，IP有一个简单的错误处理算法：丢弃该数据报，然后发送ICMP消息报给信源端。任何要求的可靠性必须由上层来提供（如TCP）。
无连接（connectionless）是指IP并不维护任何关于后续数据报的状态信息。每个数据报的处理是相互独立的。这也说明，IP数据报可以不按发送顺序接收。如果一信源向相同的信宿发送两个连续的数据报（先是A，然后是B），每个数据报都是独立地进行路由选择，可能选择不同的路线，因此B可能在A到达之前先到达。

IP 数据包的格式

IP数据报的格式如下图所示。普通的IP首部长为20个字节，除非含有选项字段。

4个字节的32 bit值以下面的次序传输：首先是0～7 bit，其次8～15 bit，然后16～23 bit，最后是24～31 bit。这种传输次序称作big endian字节序。由于TCP/IP首部中所有的二进制整数在网络中传输时都要求以这种次序，因此它又称作网络字节序。以其他形式存储二进制整数的机器，如little endian格式，则必须在传输数据之前把首部转换成网络字节序。
这里涉及到一个概念：大端字节序（big endian，也称网络字节序）和小端字节序（little endian）区别。
（1）4位版本：目前最常用的版本号是4，即IPv4。
（2）首部长度：首部占32 bit字的数目，包括任何选项。由于它是一个4bit段，因此首部最长为60个字节。普通IP数据报（没有任何选择项）字段的值是5。
（3）服务类型（TOS）：包括一个3bit的优先权子字段（现已被忽略），4 bit的TOS子字段和1 bit未用位（必须置0）。4 bit的TOS分别代表：最小时延、最大吞吐量、最高可靠性和最小费用。4 bit中只能置其中1 bit。如果所有4 bit均为0，那就意味这是一般服务。
现在大多数的TCP/IP实现都不支持TOS特性，但是自4.3BSD Reno以后的新版系统都对它进行了设置。另外，新的路由协议如OSPF和IS-IS都能根据这些字段的值进行路由决策。
（4）总长度字段（16bit）：是指整个IP数据报的长度，以字节为单位。利用首部长度字段和总长度字段，就可知IP数据报中数据内容的起始位置和长度。由于该字段长16bit，所以IP数据报最长可达65535字节。当数据报被分片时，该字段的值也随之变化。
（5）标识字段：唯一标识主机发送的每一份数据报。通常每发送一份报文它的值就会加1。
（6）TTL（time-to-live）生存时间字段：设置的数据报可以经过的最多路由器数。它指定了数据报的生存时间。TTL的初始值由源主机设置（通常为32或64），一旦经过一个处理它的路由器，它的值就减去1。当该字段的值为0时，数据报就被丢弃，并发送ICMP报文通知源主机。
（7）协议段：唯一标识向IP传送数据的协议类型。
（8）首部检验和字段：根据IP首部计算的检验和码。它仅对首部的数据进行计算。ICMP、IGMP、UDP和TCP在它们各自的首部中均含有同时覆盖首部和数据检验和码。
（9）任选项：数据报中的一个可变长的可选信息。如安全和处理限制、时间戳、记录路径等。需要说明的是，并非所有的主机和路由器都支持这些选项。选项字段一直都是以32 bit作为界限，在必要的时候插入值为0的填充字节。这样就保证IP首部始终是32 bit的整数倍（这是首部长度字段所要求的）。

IP路由选择

在一般的体制中，IP可以从TCP、UDP、ICMP和IGMP接收数据报（即在本地生成的数据报）并进行发送，或者从一个网络接口接收数据报（待转发的数据报）并进行发送。
当收到一份数据报并进行发送时，它首先要对路由表搜索一次。当数据报来自某个网络接口时，IP首先检查目的IP地址是否为本机的IP地址之一或者IP广播地址。如果确实是这样，数据报就被送到由IP首部协议字段所指定的协议模块进行处理。如果数据报的目的不是这些地址，那么如果IP层被设置为路由器的功能，那么就对数据报进行转发；否则数据报被丢弃。
IP路由选择主要完成以下这些工作：
（1) 在路由表中寻找能与目的IP地址完全匹配的表目（网络号和主机号都匹配）。如果找到，则把报文发送给该表目指定的下一站路由器或直接连接的网络接口（取决于标志字段的值）。
（2) 在路由表中寻找能与目的网络号相匹配的表目。如果找到，则把报文发送给该表目指定的下一站路由器或直接连接的网络接口（取决于标志字段的值）。
（3) 在路由表中寻找标为“默认（default）”的表目。如果找到，则把报文发送给该表目指定的下一站路由器。
（4) 如果上述表目都没有找到，则不能传送该数据报。

子网寻址

现在所有的主机都要求支持子网编址。即不再把IP地址看成由单纯的一个网络号和一个主机号组成，而是把主机号再分成一个子网号和一个主机号。一个IP地址包括：网络号、子网号、主机号。这样做的原因是因为A类和B类地址为主机号分配太多的空间。而在实际应用中，人们并不会在一个网络中安排这么多的主机。

子网掩码

通过子网掩码，可以确定一个IP地址的子网号和主机号。这个掩码是一个32 bit的值，其中值为1的比特留给网络号和子网号，为0的比特留给主机号。
给定IP地址和子网掩码以后，主机就可以确定IP数据报的目的是：(1)本子网上的主机；(2)本网络中其他子网中的主机；(3)其他网络上的主机。
如果知道本机的IP地址，那么就知道它是否为A类、B类或C类地址(从IP地址的高位可以得知)，也就知道网络号和子网号之间的分界线。而根据子网掩码就可知道子网号与主机号之间的分界线。

特殊的IP地址

主要分为三类：特殊的源地址、特殊的环回地址、广播地址。

ARP协议

ARP为IP地址到对应的硬件地址之间提供动态映射。
网络上的每个系统都具有唯一的硬件地址，它是由网络接口生产厂家配置的。无盘系统的RARP实现过程是从接口卡上读取唯一的硬件地址，然后发送一份RARP请求（一帧在网络上广播的数据），请求某个主机响应该无盘系统的IP地址（RARP应答中）。
RARP是被那些没有磁盘驱动器的系统使用（一般是无盘工作站或X终端），它需要系统管理员进行手工设置。
网络接口有一个硬件地址（一个48 bit的值，标识不同的以太网或令牌环网络接口）。在硬件层次上进行的数据帧交换必须有正确的接口地址。但是，TCP/IP的地址是一个32 bit的IP地址。知道主机的IP地址并不能让内核发送一帧数据给主机。内核（如以太网驱动程序）必须知道目的端的硬件地址才能发送数据。ARP的功能是在32 bit的IP地址和采用不同网络技术的硬件地址之间提供动态映射。
点对点链路不使用ARP协议。当设置这些链路时（一般在引导过程进行），必须告知内核链路每一端的IP地址。也就是说点对点链路并不涉及链路层地址如以太网的硬件地址。

ARP高速缓存

ARP高效运行的关键是每个主机上都有一个ARP高速缓存。这个高速缓存存放了最近Internet地址到硬件地址之间的映射记录（IP地址到硬件地址）。高速缓存中每一项的生存时间一般为20分钟，起始时间从被创建时开始算起。

ARP的分组格式

在以太网上解析IP地址时，ARP请求和应答分组的格式如下图所示：

（1）以太网的源地址和目的地址。以太网报头的前两个字段是以太网的源地址和目的地址（均是48bit的硬件地址）。当目的地址全为1时，该地址为广播地址。电缆上的所有以太网接口都要接收广播的数据帧。
（2）帧类型。对于ARP请求或应答来说，以太网帧该字段值为0x0806。
（3）硬件类型和协议类型。硬件类型字段表示硬件地址的类型。它的值为1即表示以太网地址。协议类型字段表示要映射的协议地址类型。它的值为0x0800即表示I P地址。它的值与包含IP数据报的以太网数据帧中的类型字段的值相同，这是有意设计的。
（4）硬件地址长度和协议地址长度字段。分别用来表示硬件地址长度和协议地址长度，以字节为单位。对于以太网上IP地址的ARP请求或应答来说，其值分别为6和4。
（5）操作字段（operation）。该字段共四种操作类型，它们是ARP请求（值为1）、ARP应答（值为2）、RARP请求（值为3）和RARP应答（值为4）。这个字段必需的，因为ARP请求和ARP应答的帧类型字段值是相同的。
（6）发送端的硬件地址（本例为以太网地址）、发送端的协议地址（I P地址）、目的端的硬件地址和目的端的协议地址。

ARP代理

ARP的一个特性是支持ARP代理。如果ARP请求是从一个网络的主机发往另一个网络上的主机，那么连接这两个网络的路由器就可以回答该请求，这个过程称作委托ARP或ARP代理(Proxy ARP)。这样可以欺骗发起ARP请求的发送端，使它误以为路由器就是目的主机，而事实上目的主机是在路由器的“另一边”。即，使用路由器作为目的主机的代理，把分组从其他主机转发给它。
ARP代理也称作混合ARP（promiscuous ARP）或ARP出租(ARP hack)。这些名字来自于ARP代理的其他用途：通过两个物理网络之间的路由器可以互相隐藏物理网络。在这种情况下，两个物理网络可以使用相同的网络号，只要把中间的路由器设置成一个ARP代理，以响应一个网络到另一个网络主机的ARP请求。这种技术在过去用来隐藏一组在不同物理电缆上运行旧版TCP /IP的主机。分开这些旧主机有两个共同的理由，其一是它们不能处理子网划分，其二是它们使用旧的广播地址。

免费ARP

ARP的另一个特性是支持免费ARP (gratuitous ARP)。它是指主机发送ARP查找自己的IP地址。通常，它发生在系统引导期间进行接口配置的时候。免费ARP可以有两个方面的作用：
（1）一个主机可以通过它来确定另一个主机是否设置了相同的IP地址。
（2）如果发送免费ARP的主机正好改变了硬件地址（很可能是主机关机了，并换了一块接口卡，然后重新启动），那么这个分组就可以使其他主机高速缓存中旧的硬件地址进行相应的更新。
需要说明的是，该功能并不是必须开启的。如SunOS 4.1.3和4.4 BSD在引导时都发送免费ARP，但是SVR4却没有这样做。

ICMP协议

ICMP，全称 Internet Control Message Protocol，即 Internet 控制报文协议。该协议主要用来传递差错报文以及其他需要注意的信息。ICMP报文通常被IP层或更高层协议（TCP或UDP）使用。一些ICMP报文把差错报文返回给用户进程。
ICMP协议主要用来检测网络通信故障和实现链路追踪，最典型的应用就是 ping 和 traceroute。
(1) ping
通过发送回送请求报文和回送回答报文来检测源主机到目的主机的链路是否有问题，目的地是否可达，以及通信的延迟情况。
(2) traceroute
通过发送探测报文来获取链路地址信息。
ICMP报文是在IP数据报内部被传输的。ICMP在IP报文中的位置如下：

ICMP报文格式

ICMP报文格式如下：

所有ICMP报文的前4个字节都是一样的，但是剩下的其他字节则互不相同。
8位类型字段和8为代码段：类型字段可以有15个不同的值，以描述特定类型的ICMP报文。某些ICMP报文还使用代码字段的值来进一步描述不同的条件。
检验和字段：对整个ICMP报文进行校验，使用的算法和IP首部的检验和算法形同。ICMP的检验和是必需的。

ICMP报文类型简介

ICMP报文的类型由报文中的类型字段和代码字段共同决定。ICMP报文可以分为两类：查询报文和差错报文。对于差错报文，因为需要对这种报文进行特殊处理，所以需要进行区分。如在对ICMP差错报文进行响应时，永远不会生成另一份ICMP差错报文（如果没有这个限制规则，可能会遇到一个差错产生另一个差错的情况，而差错再产生差错，这样会无休止地循环下去）。
ICMP报文类型详细分类如下：

下面各种情况都不会产生ICMP差错报文：
(1) ICMP差错报文（但ICMP查询报文可能会产生ICMP差错报文）。
(2) 目的地址是广播地址或多播地址（D类地址）的IP数据报。
(3) 作为链路层广播的数据报。
(4) 不是IP分片的第一片。
(5) 源地址不是单个主机的数据报。这就是说，源地址不能为零地址、环回地址、广播地址或多播地址。
这些规则是为了防止ICMP差错报文对广播分组响应所带来的广播风暴。

运输层

运输层面向进程，为进程之间提供端到端的逻辑通信。运输层向高层用户屏蔽了下面网络核心的细节，它使进程好像在两个运输层实体间有一条端到端的逻辑通信信道。

TCP协议

TCP（Transmission Control Protocol，传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC793标准定义。

TCP报文格式

TCP报文的数据结构如下：

(1) 端口号(Port, 16 bits)
端口号用来标识一台计算机的不同的应用进程。端口号占用16位，因此端口号的范围是0~65536(2^16)。TCP报文中端口号有两个： 源端口号(Source Port)和目的端口号(Destination Port)。其中，源端口定义报文发送端口，源端口和源IP地址可用于标识报文的返回地址（也是报文发送地址）。目的端口定义报文接收端口，用于指明接收方计算机的应用程序端口。
TCP报头中的源端口号和目的端口号同IP数据报中的源IP与目的IP唯一确定一条TCP连接。更多端口号相关介绍参考补充章节。
(2) 序列号(Sequence number, 32 bits = 1 Byte)
(3) 确认号(32 bits = 1 Byte)
是TCP可靠传输的关键部分。序号是本报文段发送的数据组的第一个字节的序号。在TCP传送的流中，每一个字节一个序号。e.g.一个报文段的序号为300，此报文段数据部分共有100字节，则下一个报文段的序号为400。所以序号确保了TCP传输的有序性。确认号，即ACK，指明下一个期待收到的字节序号，表明该序号之前的所有数据已经正确无误的收到。确认号只有当ACK标志为1时才有效。比如建立连接时，SYN报文的ACK标志位为0。
(4) 数据偏移(Data Offset, 4bits)
数据偏移用来指定TCP报文的大小（以32字节为单位）。数据偏移字段占用4位，因此所能表示的最大值为1111，转化为10进制为15，15*32/8 = 60，故报头最大长度为60字节。 又因为TCP报头在不含任何可选字段时，其长度为20字节。所以TCP报文的size在20字节到60字节之间，而数据偏移字段的最小值是0101，最大值为1111。注意，数据偏移字段代表从TCP报文开始位置到实际数据的偏移量。(Specifies the size of the TCP header in 32-bit words. The minimum size header is 5 words and the maximum is 15 words thus giving the minimum size of 20 bytes and maximum of 60 bytes, allowing for up to 40 bytes of options in the header. This field gets its name from the fact that it is also the offset from the start of the TCP segment to the actual data.)
(5) 保留(Reserved, 3 bits)
保留位，用于扩展新功能。默认置零即可。
(6) 控制位(Control Bits, 9 bits)
共九个控制位，每个控制位占用一个字节，代表一个控制功能。
NS (Explicit Congestion Notification (ECN) Signaling with Nonces, 基于随机数的显式拥塞通知信令): 实验性标识位，参考RFC 3540)。
CWR (Congestion Window Reduced, 减少拥塞窗口)：减少拥塞窗口标识位由发送方设置，用来指示接收到带有ECE标志设置的TCP报文后，已通过拥塞控制机制做出响应，可参考RFC 3168。is set by the sending host to indicate that it received a TCP segment with the ECE flag set and had responded in congestion control mechanism (added to header by RFC 3168).
ECE (ECN-Echo, ECN返回): 有双重作用（a dual role），具体取决于SYN标志的值：1) 如果设置SYN标志位为1，则表示TCP对等端具有ECN功能; 2)如果SYN标志置零，则表示在正常传输过程中收到IP标头中设置拥塞经历标志（ECN = 11）的数据包。表示TCP发送方出现网络拥塞（或即将发生拥塞）。
URG(URGent pointer, 紧急指针标识)，该值为1时表示紧急指针有效，为0则忽略紧急指针。
ACK (ACKnowledgment field, 确认字段标识)，为1时表示确认字段有效，为0表示报文中不含确认信息，忽略确认字段。客户端发送的初始SYN数据包之后的所有数据包都应设置此标志。
PSH (PuSH function, 推送功能标识) ，为1时表示接收方在接收到该报文后，应尽快将这个报文交给应用程序，而不是在缓冲区排队。
RST (ReSeT the connection, 重置连接标识)，为1时重置连接。主要用于重置由于主机崩溃或其他原因而出现错误的连接，或者用于拒绝非法的报文段和拒绝连接请求。
SYN (SYNchronize sequence numbers, 同步序列号标识)，为1时，表示建立连接。其他一些标志和字段会根据此标志更改含义，一些仅在设置时有效，而其他一些则在清除时有效。
FIN (Finish, 完成标志): 为1时，表示该数据包是发送方的最后一个数据包。用于释放连接，即关闭本方数据流。
(7) 窗口(Window, 16 bits)
滑动窗口大小，用来告知发送端缓存大小，以此控制发送数据的速率，从而达到流量控制。窗口的范围是0~65535(2^16)。
(8) 校验和(Checksum, 16 bits)
奇偶校验，校验值是对整个TCP报文进行校验，包括TCP头部和TCP数据。由发送端计算和存储，并由接收端验证。
(9) 紧急指针(Urgent pointer, 16 bits)
当且仅当URG标识位设置为1时，该指针才生效。URG标识位和紧急指针一起实现了紧急数据的发送。
(10) 选项和填充（Option, 0~40 Byte）
选项长度不一定是32位的整数倍，所以要加填充位，即在这个字段中加入额外的零，以保证TCP头是32的整数倍。
最常见的选项的长度是最长报文大小，又称为MSS（Maximum Segment Size），每个连接方通常都在通信的第一个报文段（为建立连接而设置SYN标志为1的那个段）中指明这个选项，它表示本端所能接受的最大报文段的长度。
(11) 数据（Data，长度不固定）
TCP报文中的数据部分是可选的。在一个连接建立和一个连接终止时，双方交换的报文段仅有TCP首部。如果一方没有数据要发送，则没有必要使用没有任何数据的首部来确认收到的数据。在处理超时，也会发送不带任何数据的报文段。

TCP三次握手、TCP四次挥手

TCP是面向连接的通信协议，也就是说在进行通信前，发送方和接受方已建立了连接，并在完成通信后，释放连接。
(1) 建立TCP连接
TCP连接建立的过程就是三次握手的过程，因此也将建立TCP连接的过程称为三次握手。三次握手图示如下：

最初，客户端和服务器的TCP进程都处于CLOSED(关闭)状态。对于服务器端来说，为时刻准备接收客户端进程的连接请求，需提前进入LISTEN（监听）状态，注意，此时服务器的连接并未打开。
然后，客户端TCP进程在创建传输控制块TCB后，主动向服务器发出TCP连接请求报文。此时，报文头部中的同步标识位SYN=1，并设置一个初始序列号seq=x。发送完TCP连接请求报文后，客户端TCP进程进入到SYN-SENT（同步已发送状态）状态。注意，这个报文（SYN=1的报文）不能携带数据，且需要消耗掉一个序列号。
接着，服务器TCP进程接收到请求报文，如果同意连接，则发出确认报文。服务器端确认报文中确认标识位ACK=1，同步标识位SYN=1，确认号ack=x+1，同时也要初始化一个序列号 seq=y。发送完确认报文后，服务器TCP进程进入SYN-RCVD（同步收到）状态。注意，这个报文(ACK=1, SYN=1的报文)也不能携带数据，且同样需要消耗一个序号。
之后，客户端TCP进程接收到服务器端确认报文，并要向服务器给出确认。客户端确认报文的确认标识ACK=1，确认号ack=y+1，序列号seq=x+1。客户端发送完确认报文后，进入ESTABLISHED（已建立连接）状态。注意，这个报文(ACK=1的报文)可以携带数据，但如果不携带数据则不消耗序号。
此后，服务器TCP进程接收到客户端的确认报文后也进入ESTABLISHED状态。
最后，双方就可以开始通信。
建立TCP连接过程的三次握手可总结如下：
第一次握手：客户端TCP进程发送请求连接报文（SYN=1, seq=x）的数据包到服务器TCP进程。此时客户端TCP进程进入SYN_SEND状态，并等待服务器确认。注意，此时服务器端仍位LISTEN状态。
第二次握手：服务器TCP进程收到客户端请求连接报文后，发送确认报文，同时也发送一个SYN包（ACK=1, SYN=1, seq=y,ack=x+1），此时服务器进入SYN_RECV状态。注意，此时客户端仍为SYN_SEND状态。
第三次握手：客户端TCP进程收到服务器确认报文后，向服务器发送客户端确认保文(ACK=1, ack=y+1)，并进入ESTABLISHED状态，服务器TCP进程在接收到客户端的确认报文后，也进入到ESTABLISHED状态。
注意：
理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP连接都将被一直保持下去。
以A和B代表两个连接终端，三次握手时状态变化可总结为：A、B关闭状态CLOSED——B收听状态LISTEN——A同步已发送状态SYN-SENT——B同步收到状态SYN-RCVD——A、B连接已建立状态ESTABLISHED
三次握手辨析：
1）三次握手是否可改为两次握手
三次握手不可改为两次握手。这主要是为了防止已失效的连接请求报文突然又传送到了服务器端，从而产生错误。假如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端又重传一次连接请求。之后客户端收到确认并建立连接。如果客户端的第一个请求仅仅是存在网络延迟，当在客户端已和服务器建立连接后达到服务器后，服务器会认为客户端又发出一次新的连接请求，于是向客户端发出确认报文。如果采用三次握手，服务器就可确认因网络延迟的请求连接报文是一个重复报文。
2）三次握手存在SYN攻击危险
服务器资源分配时机是在第二次握手，而客户端资源分配是在第三次握手，所以服务器容易受到SYN洪泛攻击。所谓SYN攻击就是指客户端在短时间内伪造大量不存在的IP地址，并向服务器不断地发送SYN包，服务器回复确认报文后，会等待客户端确认，但由于源地址不存在，所以服务器需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。
注意：SYN攻击只能防范，无法避免。常见的防范措施有：降低主机的等待时间以使主机尽快释放半连接的占用，短时间受到某IP的重复SYN则丢弃后续请求等。
(2) 释放TCP连接
数据传输完毕后，双方都需释放连接。TCP释放建立的过程就是四次握手的过程，为与三次握手进行区分，将释放TCP连接的过程称为四次挥手。四次挥手图示如下：
最初，客户端和服务器都处于ESTABLISHED状态。然后客户端TCP进程发出连接释放报文，并且停止发送数据。此时释放连接报文头部中结束标识位FIN=1，并更新序列号seq=u（等于前面已传送数据的最后一个字节的序列号加1），发送完TCP连接释放请求报文后，客户端TCP进程进入FIN-WAIT-1（终止等待1）状态。 注意，这个报文(FIN=1的报文)即使不携带数据，也要消耗一个序列号。
然后，服务器TCP进程接收到连接释放报文后，发出确认报文，确认标识位ACK=1，确认号ack=u+1，并且初始化一个序列号seq=v。服务器TCP进程发送完确认报文后，进入到CLOSE-WAIT（关闭等待）状态。此时，客户端向服务器的连接就释放了，也就是处于半关闭状态：客户端已经没有数据要发送，但服务器若发送数据，客户端依然要接受。
接着，客户端TCP进程接收到服务器的确认请求后，进入到FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
之后，服务器TCP进程将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端确认。
在这之后，客户端TCP进程接收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2MSL（Maximum Segment Lifetime，最长报文段寿命）时间后，客户端TCP进程才进入CLOSED状态。
而服务器TCP进程在接到客户端的连接释放确认报文后，立即进入CLOSED状态。所以，服务器TCP进程结束TCP连接的时间要比客户端早一些。
释放TCP连接的四次挥手可总结如下：
第一次挥手：客户端TCP进程发送释放连接报文(FIN=1, seq=u) 到服务器TCP进程。此时客户端TCP进程进入FIN-WAIT-1（终止等待1）状态。注意，注意，此时，服务器端仍处于ESTABLISHED状态。
第二次挥手：服务器TCP进程收到客户端释放连接报文后，发送确认报文，同时也发送一个SYN包（ACK=1, ack=u+1, seq=v），然后服务器进入CLOSE-WAIT状态。注意，当前连接已处于半关闭状态。客户端已无法向服务器发送数据，但客户端仍可接收服务器发送到数据。
客户端TCP进程接收到服务器的确认请求后，进入到FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
第三次挥手：服务器TCP进程确认最后的数据发送完毕后，向客户端发送连接释放报文(FIN=1, ack=u+1, seq=w)，然后，服务器就进入了LAST-ACK（最后确认）状态，等待客户端确认。
第四次挥手：客户端TCP进程接收到服务器的连接释放报文后，返回确认报文(ACK=1, ack=w+1, seq=u+1)，然后客户端就进入TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2*MSL时间后，客户端TCP进程才进入CLOSED状态。而服务器TCP进程在接到客户端的连接释放确认报文后，立即进入CLOSED状态。
四次挥手的状态转换过程如下：
客户端和服务器处于ESTABLISHED——客户端FIN-WAIT-1——服务器CLOSE-WAIT——客户端FIN-WAIT-2——服务器LAST-ACK——客户端TIME-WAIT——服务器和客户端CLOSED
四次挥手辨析：
1）为什么客户端在TIME-WAIT状态下必须等待2MSL的时间后才关闭连接
有两个原因：a）保证客户端发送的最后一个ACK报文能够到达服务器；b）防止“已失效的连接请求报文”出现在本连接中。
a）网络是不可靠的，所以这个ACK报文段有可能丢失，使得处于LAST-ACK状态的服务器无法接收到对已发送的FIN+ACK报文的确认，服务器超时重传FIN+ACK报文，而客户端能在2MSL时间内收到这个重传的FIN+ACK报文，然后重传一次确认，并重新启动2MSL计时器，最后服务器和客户端都进入到CLOSED状态。若客户端在TIME-WAIT状态时不等待一段时间，而是发送完ACK报文段后立即释放连接，则无法收到服务器重传的FIN+ACK报文，所以不会再发送一次确认报文，那么服务器将无法正常进入到CLOSED状态。
b）客户端在发送完最后一个ACK报文后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文。
2）为什么TCP连接时需要三次握手，而关闭时却是四次握手
这是因为在连接到时候，服务器接收到客户端的SYN连接请求报文后，可直接返回SYN+ACK报文（其中ACK报文是用来应答的，SYN报文是用来同步的）。但关闭连接时，服务器接收到FIN报文后，有时无法立即关闭SOCKET，这是因为服务器仍在向客户端发送之前请求的数据。所以只能先回复释放连接确认报文，以告诉客户端接收到其连接释放请求。这样，当服务器发送完报文后，就可发送连接释放报文。故需要四步握手。

TCP短连接和长连接

(1) HTTP短连接和长连接
在HTTP1.0中，默认使用的短连接。也就是说，浏览器和服务器每进行一次HTTP操作，就建立一次连接，并在任务结束后中断连接。如客户端向服务器请求多个Web资源（JavaScript文件、图像文件、CSS文件等）时，每个Web资源都需要单独的HTTP连接来获取。
但在HTTP1.1中，默认使用长连接。在使用长连接时，一个请求完成后，客户端和服务器之间用于传输HTTP数据的TCP连接并不会关闭，当客户端再次向这个服务器请求资源时，可以继续使用该已经建立的连接，而无需重新建立连接。注意，长连接不是永久连接，它有一个保活时间，可以在不同的服务器软件（如Apache）中设定这个时间。使用长连接的HTTP协议时，会检测到响应头(Response Header)的Connection属性的值为keep-alive。注意，keep-alive不代表永久保持连接，它有一个保活时间，可以在不同的服务器软件（如Apache）中设定这个时间。
HTTP协议的长连接和短连接实质上是传输层TCP协议的长连接和短连接功能在应用层的体现。如果需要深入了解HTTP的短连接和长连接，就需要深入TCP短连接和长连接的实现原理。
(2) TCP长连接与短连接简介
长连接指在一个TCP连接上可以连续发送多个数据包，在TCP连接保持期间，如果没有数据包发送，需要双方发检测包以维持此连接，一般需要自己做在线维持（不发送RST (Reset)包（连接异常终止）和四次挥手）。
短连接是指通信双方有数据交互时，就建立一个TCP连接，在数据发送完成后，就断开此TCP连接。
(3) TCP长连接与短连接执行流程简介
短连接：
连接->数据传输->关闭连接
长连接：
连接->数据传输->保持连接(心跳)->数据传输->保持连接(心跳)->…->关闭连接（一个TCP连接存在多个读写通信）
可见，长连接在没有数据通信时，需要定时发送数据包(心跳)，以维持连接状态，而短连接在没有数据传输时直接关闭，不存在连接状态的维持。
(4) TCP Keepalive(保活)功能简介
TCP保活功能主要为服务器应用提供，服务器应用希望知道客户主机是否崩溃，从而可以代表客户使用资源。如果客户已经消失，使得服务器上保留一个半开放的连接，而服务器又在等待来自客户端的数据，则服务器将永远等待客户端的数据，保活功能就是试图在服务器端检测到这种半开放的连接。
如果一个给定的连接在两小时内没有任何的动作，则服务器就向客户发一个探测报文，客户端必须处于以下4个状态之一：
1）客户主机依然正常运行，并从服务器可达。客户的TCP响应正常，而服务器也知道对方是正常的，服务器在两小时后将保活定时器复位。
2）客户主机已经崩溃，并且关闭或者正在重新启动。在任何一种情况下，客户的TCP都没有响应。服务端将不能收到对探测的响应，并在75秒后超时。服务器总共发送10个这样的探测 ，每个间隔75秒。如果服务器没有收到一个响应，它就认为客户主机已经关闭并终止连接。
3 客户主机崩溃并已经重新启动。服务器将收到一个对其保活探测的响应，这个响应是一个复位，使得服务器终止这个连接。
3）客户机正常运行，但是服务器不可达，这种情况与2类似，TCP能发现的就是没有收到探查的响应。
在实际应用中，有三种使用 KeepAlive 的实践方案：
a) 默认情况下使用 KeepAlive 周期为 2 个小时，如不选择更改，属于误用范畴，造成资源浪费：内核会为每一个连接都打开一个保活计时器，N 个连接会打开 N 个保活计时器。 优势很明显：TCP 协议层面保活探测机制，系统内核完全替上层应用自动给做好了；内核层面计时器相比上层应用，更为高效；上层应用只需要处理数据收发、连接异常通知即可；数据包将更为紧凑；
b) 关闭 TCP 的 KeepAlive，完全使用应用层心跳保活机制。由应用掌管心跳，更灵活可控，比如可以在应用级别设置心跳周期，适配私有协议；
c) 业务心跳 + TCP KeepAlive 一起使用，互相作为补充，但 TCP 保活探测周期和应用的心跳周期要协调，以互补方可，不能够差距过大，否则将达不到设想的效果。
(5) HTTP keepalive与TCP keepalive
HTTP协议的Keepalive指明连接复用，这样在同一个连接上就可使用串行方式传递请求-响应数据；
TCP协议的Keepalive则在于保活、心跳检测，用于探测连接的探测连接的对端是否存活。
(6) 长连接和短连接对比
长连接可以节省TCP连接重复建立和关闭的资源开销和时间开销，适用于频繁请求资源的用户。但长连接的默认keepalive机制存在两个问题：1) 保活功能的探测周期太长（默认是两小时）；2) 无法区分恶意连接和正常连接。在长连接模式下，存在服务器无法承担过多客户端连接的问题，为解决这个问题，可采取一些策略，如关闭一些长时间没有读写事件发生的连接；如以客户端为颗粒度，限制每个客户端的最大长连接数。另外，也可禁用TCP的KeepAlive机制，在客户端实现心跳保活机制，等等。
短连接较为简单，连接在完成数据传输后就关闭，无需维护连接。但短连接不适用于频繁请求资源的用户。

拥塞控制(Congestion Control)

所谓拥塞就是对网络中的某一资源的需求超过了该资源所能提供的可用部分。拥塞会导致网络的性能随着负荷的增大而下降。
拥塞控制就是防止过多的数据注入到网络中，以保证网络中的路由器或链路不致过载。拥塞控制的前提是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机、路由器，以及与降低网络传输性能有关的所有因素。拥塞控制的代价是需要获得网络内部流量分布的信息。在实施拥塞控制之前，还需要在结点之间交换信息和各种命令，以便选择控制的策略并实施控制。根据端到端原则，拥塞控制主要是Internet主机的功能，而不是网络本身的功能。(Per the end-to-end principle, congestion control is largely a function of internet hosts, not the network itself.)
拥塞控制： 发送端主动控制cwnd(congestion window, 拥塞窗口，发送端窗口)，有慢启动（从cwnd初始为1开始启动，指数启动），拥塞避免（到达ssthresh(slow-start threshold, 慢启动阈值)后，为了避免拥塞开始尝试线性增长），快重传（接收方每收到一个报文段都要回复一个当前最大连续位置的确认，发送方只要一连收到三个重复确认就知道接收方丢包了，快速重传丢包的报文，并马上把拥塞窗口 cwnd 减小到1），快恢复（直接从ssthresh线性增长）。
(1) 慢启动(Slow Start)
当发送端开始发送数据时，如果立即将大量数据字节注入到网络，那么就有可能因为不清楚当前网络的负荷情况而引起拥塞。所以，最好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是说，由小到大逐渐增大拥塞窗口数值。通常在刚刚发送报文段时，先把拥塞窗口cwnd设置为一个最大报文段(MSS, Maximum Segment Size)的数值。而在每收到一个新的报文段的确认后，把拥塞窗口增加至多一个MSS的数值(指数级增长)。用这样的方法逐步增大发送方的拥塞窗口cwnd，可以使分组注入到网络的速率更加合理。
当rwnd的值足够大时，为了防止拥塞窗口cwnd过度增长引起拥塞，还需设置阈值。在慢启动中将这个阈值称为ssthresh。
(2) 拥塞避免(Congestion Avoidance)
当cwnd的值大于ssthresh时，将停用慢启动算法，改用拥塞避免算法。(When the congestion window exceeds the slow-start threshold, ssthresh, the algorithm enters a new state, called congestion avoidance.)
拥塞避免是调整了拥塞窗口的增加规律，将慢启动过程中拥塞窗口的指数级增长调整成按照线性级增加。
注意，无论是慢启动算法还是拥塞避免算法，只要判断网络出现拥塞，就要把ssthresh设置为发送窗口的一半（>=2），cwnd设置为1，然后再使用慢启动算法。这样做的目的能迅速的减少网络当中的数据传输，使发生拥塞的路由器能够把队列中堆积的分组处理完毕。
(3) 快重传(Fast Retransmit)
一条TCP连接有时会因为等待重传计时的超时而空闲较长时间，慢开始和拥塞避免无法解决这类问题，因此提出了快重传和快恢复的拥塞控制方法。
快重传算法要求首先接收方收到一个失序的报文段后立刻发出重复确认，而不要等待自己发送数据时才进行捎带确认。
(4) 快恢复(Fast Recovery)
发送方现在认为网络很可能没有发生阻塞，因此现在不执行慢启动算法，而是把cwnd值设置为慢启动门限减半后的值，然后开始执行拥塞避免算法，拥塞窗口cwnd值线性增大。

流量控制(Flow Control)

为了提高信道的利用率TCP协议不使用停止等待协议，而是使用连续ARQ协议，意思就是可以连续发出若干个分组然后等待确认，而不是发送一个分组就停止并等待该分组的确认。但是使用这种协议后，如果发送方把数据发送得过快，接收方可能会来不及接收，这就会造成数据的丢失。所谓流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。(TCP uses an end-to-end flow control protocol to avoid having the sender send data too fast for the TCP receiver to receive and process it reliably. Having a mechanism for flow control is essential in an environment where machines of diverse network speeds communicate. For example, if a PC sends data to a smartphone that is slowly processing received data, the smartphone must regulate the data flow so as not to be overwhelmed(使应接不暇, 使不知所措).)
流量控制是指接收端流量控制，而接收端的应用层处理速度决定和网速无关，由接收端返回的rwnd控制。利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。示例如下：
设A向B发送数据。在连接建立时，B告诉了A：“我的接收窗口是 rwnd = 400 ”(这里的 rwnd 表示 receiver window) 。因此，发送方的发送窗口不能超过接收方给出的接收窗口的数值。请注意，TCP的窗口单位是字节，不是报文段。TCP连接建立时的窗口协商过程在图中没有显示出来。再设每一个报文段为100字节长，而数据报文段序号的初始值设为1。大写ACK表示首部中的确认位ACK，小写ack表示确认字段的值ack。

重传控制(Retransmission Control)

超时重传指的是，发送数据包在一定的时间周期内没有收到相应的ACK，当等待的时间超过RTO(Retransmission TimeOut，重传超时时间)，则认为这个数据包丢失，就会重新发送这个数据包。

UDP协议

UDP（User Datagram Protocol，用户数据报协议）是一种面向无连接的、不可靠的、基于数据报文的传输层通信协议，由IETF的RFC768标准定义。

UDP报文格式

UDP报文的数据结构如下：

(1) 源端口(Source port number)
This field identifies the sender’s port, when used, and should be assumed to be the port to reply to if needed. If not used, it should be zero. If the source host is the client, the port number is likely to be an ephemeral port number. If the source host is the server, the port number is likely to be a well-known port number.
(2) 目标端口号(Destination port number)
This field identifies the receiver’s port and is required. Similar to source port number, if the client is the destination host then the port number will likely be an ephemeral port number and if the destination host is the server then the port number will likely be a well-known port number.
(3) 长度(Length)
This field specifies the length in bytes of the UDP header and UDP data. The minimum length is 8 bytes, the length of the header. The field size sets a theoretical limit of 65,535 bytes (8 byte header + 65,527 bytes of data) for a UDP datagram. However the actual limit for the data length, which is imposed by the underlying IPv4 protocol, is 65,507 bytes (65,535 − 8 byte UDP header − 20 byte IP header).
Using IPv6 jumbograms it is possible to have UDP packets of size greater than 65,535 bytes. RFC 2675 specifies that the length field is set to zero if the length of the UDP header plus UDP data is greater than 65,535.
长度：UDP报文的整个大小，最小为8个字节（仅为首部）。
(4) 校验和(Checksum)
The checksum field may be used for error-checking of the header and data. This field is optional in IPv4, and mandatory in IPv6. The field carries all-zeros if unused.
检验和：在进行检验和计算时，会添加一个伪首部一起进行运算。伪首部（占用12个字节）为：4个字节的源IP地址、4个字节的目的IP地址、1个字节的0、一个字节的数字17、以及占用2个字节UDP长度。这个伪首部不是报文的真正首部，只是引入为了计算校验和。相对于IP协议的只计算首部，UDP检验和会把首部和数据一起进行校验。接收端进行的校验和与UDP报文中的校验和相与，如果无差错应该全为1。如果有误，则将报文丢弃或者发给应用层、并附上差错警告。
UDP in IPv4

UDP in IPv6

TCP协议和UDP协议对比

TCP协议和UDP协议对比如下：

通过上图的对比可知：
TCP与UDP的不同本质上表现在可靠性上。TCP为保证可靠性，使用了面向连接、以字节为传输单位、点对点传输等机制。而这是以牺牲实时性和**增加系统资源的占用为代价的。相反，UDP无需保证可靠性，所以可以实现无连接、以报文为传输单位、一对多或多对多传输等功能，所以可以保证更好的实时性并相对减少系统资源的占用。
TCP和UDP对应应用层协议：

所以UDP可适用于实时且允许丢包的应用场景，如IP电话、视频会议、直播等。而TCP适用于要求可靠传输的应用，例如文件传输等。

应用层

DNS协议

DNS查询过程

用户访问网页，DNS服务器（域名解析系统）会根据用户提供的域名查找对应的IP地址。域名解析服务器是基于UDP协议实现的一个应用程序，通常通过监听53端口来获取客户端的域名解析请求。
DNS查询过程如下：
(1) 当在浏览器中输入URL后，操作系统会先检查自己本地的hosts文件是否有这个网址映射关系，如果有，就先调用这个IP地址映射，完成域名解析。
(2) 如果hosts里没有这个域名的映射，则查找本地DNS解析器缓存，是否有这个网址映射关系，如果有，直接返回，完成域名解析。
(3) 如果hosts与本地DNS解析器缓存都没有相应的网址映射关系，首先会找TCP/IP参数中设置的首选DNS服务器，在此我们叫它本地DNS服务器，此服务器收到查询时，如果要查询的域名，包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析，此解析具有权威性。
(4) 如果要查询的域名，不由本地DNS服务器区域解析，但本地DNS服务器缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析，此解析不具有权威性。
(5) 如果本地DNS服务器本地区域文件与缓存解析都失效，则根据本地DNS服务器的设置（是否设置转发器）进行查询，如果未用转发模式，本地DNS就把请求发至13台根DNS，根DNS服务器收到请求后会判断这个域名(.com)是谁来授权管理，并会返回一个负责该顶级域名服务器的一个IP。本地DNS服务器收到IP信息后，将会联系负责.com域的这台服务器。这台负责.com域的服务器收到请求后，如果自己无法解析，它就会找一个管理.com域的下一级DNS服务器地址给本地DNS服务器。当本地DNS服务器收到这个地址后，就会找域服务器，重复上面的动作，进行查询，直至找到主机。
(6) 如果用的是转发模式，此DNS服务器就会把请求转发至上一级DNS服务器，由上一级服务器进行解析，上一级服务器如果不能解析，或找根DNS或把转请求转至上级，以此循环。不管是本地DNS服务器用是是转发，还是根提示，最后都是把结果返回给本地DNS服务器，由此DNS服务器再返回给客户机。

HTTP协议

HTTP协议，直译为超文本传输协议，是一种用于分布式、协作、超媒体的信息系统的应用协议。HTTP协议是万维网数据通信的基础。HTTP协议在客户端-服务器计算模型中充当请求-响应协议。客户端向服务器提交HTTP请求消息。服务器提供HTML文件和其他内容等资源，或代表客户端执行其他功能，并向客户端返回响应消息。
HTTP（超文本传输协议）被用于在Web浏览器和网站服务器之间，以明文方式传递信息，不提供任何方式的数据加密，因此使用HTTP协议传输隐私信息（如：银行卡号、密码等支付信息）非常不安全。
HTTP 协议标准可以参考官网。HTTP协议的主要特点可概括如下：
(1) 支持客户/服务器模式（现在更多的应用在浏览器-服务器模式中）。
(2) 简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
(3) 灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
(4) 无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
(5) 无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。（使用Cookie和Sesseion记录数据）

HTTP 工作原理简介

HTTP 协议采用了请求/响应模型。客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头和请求数据。服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。请求/响应模型示例如下：

HTTP 请求/响应一般可分为六步：(1) 建立TCP连接;(2) 发送HTTP请求;(3) 服务器处理请求;(4) 返回HTTP响应;(5) 释放TCP连接;(6) 浏览器解析返回的资源和数据。更详细的介绍可以参考笔者浏览器输入URL后的执行过程一文。
(1) 建立TCP连接。一个HTTP客户端，通常是浏览器，主动与Web服务器的HTTP端口（默认为80）建立一个TCP套接字连接。TCP连接建立的过程也被称为“三次握手”。
(2) 发送HTTP请求。通过TCP三次握手建立好连接后，浏览器便可以将HTTP请求报文发送给服务器。一个请求报文由请求行、请求头部、空行和请求数据4部分组成。
(3) 服务器处理请求。Web服务器解析请求，定位请求资源。再通过相应的这些资源文件处理用户请求和参数，并调用数据库信息，最后将结果通过Web服务器返回给浏览器。
(4) 返回HTTP响应。Web服务器将资源复本写到TCP套接字，由客户端读取。一个响应报文由响应行、响应头部、空行和响应数据4部分组成。
(5) 释放TCP连接。若connection 模式为close，则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接;若connection 模式为keepalive，则该连接会保持一段时间，在该时间内可以继续接收请求。TCP连接的释放也被称为"四次挥手"。
(6) 浏览器解析返回的资源和数据。浏览器首先解析状态行，查看请求是否成功的状态码。然后解析每一个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集。浏览器读取响应数据html，根据html的语法对其进行格式化，并在浏览器窗口中显示。

URI、URL 和 URN 的区别

简单来说，URI 用来标识资源的唯一性，URL 则用来通过一个唯一的地址定位一个资源；URN 则通过一个唯一的名称命名一个资源。注意，URN开头必须使用"urn"这一特殊符号来标识。
URI是URL和URN的超集。URL是URI的子集，除了识别资源外，还通过描述其主要访问机制（例如其网络“位置”）来提供定位资源的手段。URN也是URI的子集，是一个通过名字来标识资源的字符串。对于URN来说，即使资源不再存在或变得不可用，也需要保持全局唯一性和持久性。URI、URL、 URN 三者差异的图示如下：

HTTP Request

HTTP Request(HTTP 请求)是客户端向服务端发送请求动作，告知服务器自己的要求。HTTP请求由状态行、消息头、空行、消息正文四个部分组成。其中，状态行包括请求方式Method、资源路径URL、协议版本Version；消息头包括一些访问的域名、用户代理、Cookie等信息；消息正文就是HTTP请求的数据；空行位于消息头和消息正文之间，用于分隔消息头和消息正文。HTTP 请求结构如下：
(1) 状态行
状态行在 HTTP 请求中也被称为“请求行”，包含请求方法、资源路径URL、协议版本三个部分。其中：
(a) 请求方法常见的有：GET、POST、HEAD、OPTIONS、PUT、DELETE、TRACE、CONNECT、PATCH；
(b) 资源路径URL就是用来定位资源在Internt的位置；
© 协议版本指明当前使用HTTP协议版本。
(2) 消息头
消息头在 HTTP 请求中也被称为“请求头”。消息头由一系列键值对组成。包括访问的域名、用户代理、Cookie等信息。这里介绍一些常用键值对。
Host 是请求报头域，用于指定被请求资源的 Internet 主机和端口号，它通常从 HTTP URL 中提取出来。
Connection 表示连接状态，keep-alive 表示该连接是持久连接（persistent connection），即 TCP 连接默认不关闭，可以被多个请求复用，如果客户端和服务器发现对方有一段时间没有活动，就可以主动关闭连接。
User-Agent 用于标识请求者的一些信息，比如浏览器类型和版本，操作系统等。
Accept 用于指定客户端希望接受哪些类型的信息，比如 text/html, image/gif 等。
Cookie 用于维护状态，可做用户认证，服务器检验等，它是浏览器储存在用户电脑上的文本片段。
(3) 消息正文
消息正文，也称“请求正文”，记录请求消息主体。

HTTP Response

HTTP Response(HTTP 响应)是服务器返回给客户端已发送HTTP请求的执行结果。HTTP 响应和HTTP请求一样，由四部分组成：状态行、消息头、空行、消息正文。其中，状态行包括协议版本Version、状态码Status Code、状态消息等内容；消息头包括搭建服务器的软件，发送响应的时间，回应数据的格式等信息；消息正文就是HTTP响应的数据。空行位于消息头和消息正文之间，用于分隔消息头和消息正文。HTTP 响应结构如下：

(1)状态行
状态行在HTTP响应中也被称为“响应行”。响应行由HTTP协议版本号，状态码，状态消息三部分组成。其中：
(a) 协议版本，与HTTP请求行中协议版本作用一致，用来指明当前使用HTTP协议版本；
(b) 状态码，用以表示服务器响应状态的三位数字代码。
(2) 消息头
消息头在 HTTP响应中也被称为“响应头”，与HTTP请求的请求头一致，由一系列键值对组成。消息头包括访消息头包括搭建服务器的软件，发送响应的时间，回应数据的格式等信息。这里介绍一些常用键值对。
Connection 表示连接状态，和请求头中该属性作用一致。
Server 记录服务器用来处理请求的软件信息，跟请求报头域 User-Agent 相对应。
Content-Type 用于指定发送给接收者（如浏览器）响应正文的MIME（媒体）类型，比如 text/html, text/css, image/png, image/jpeg, video/mp4, application/pdf, application/json 等，编码类型是UTF-8。（实现超媒体的入口）
Content-Length 指明本次回应的数据长度。
Date 生成响应的日期和时间。
(3)消息正文
消息正文，也称“响应正文”，记录响应消息主体。

HTTP请求方法

根据HTTP标准，HTTP请求可以使用多种请求方法。
HTTP0.9定义了 GET 请求方法。
HTTP1.0定义了 POST 和 HEAD请求方法。
HTTP1.1新增了 OPTIONS, PUT, DELETE, TRACE, CONNECT 和 PATCH请求方法。

GET         获取资源。请求指定的页面信息，并返回实体主体。  
HEAD        获取响应消息报头。类似于get请求，只不过返回的响应中没有具体的内容。  
POST        传输实体数据。向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。  
DELETE      删除资源。请求服务器删除指定的页面。  
PUT         传输文件。从客户端向服务器传送的数据取代指定文档的内容。  
PATCH       局部更新已知资源。对 PUT 方法的补充，用来对已知资源进行局部更新。  
CONNECT     更改连接为管道方式的代理服务求。HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。  
OPTIONS     查询服务器的性能，或者查询与资源相关的选项和需求。  
TRACE       回显服务器收到的请求，主要用于测试或诊断。  

HTTP状态码

状态代码有三位数字组成，并使用第一个数字定义响应的类别，共分五类:
1xx：指示信息–表示请求已接收，请求者继续执行操作
2xx：请求成功–表示请求已被成功接收、理解、接受
3xx：请求重定向–要完成请求必须进行更进一步的操作
4xx：客户端错误–请求有语法错误或请求无法实现
5xx：服务器端错误–服务器未能实现合法的请求
常见状态码有：

200 OK                        //客户端请求成功  
400 Bad Request               //客户端请求有语法错误，不能被服务器所理解  
401 Unauthorized              //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用  
403 Forbidden                 //服务器收到请求，但是拒绝提供服务  
404 Not Found                 //请求资源不存在，eg：输入了错误的URL  
429 Too Many Requests         //在一定的时间内用户发送了太多的请求，即超出了“频次限制”  
500 Internal Server Error     //服务器发生不可预期的错误  
503 Server Unavailable        //服务器当前不能处理客户端的请求，一段时间后可能恢复正常  

Cookie和Session

Cookie，是W3C组织提出，可看成HTTP协议的一个扩展，由Netscape社区发展而来的一种会话跟踪技术。目前Cookie已经成为业内标准，可在所有的主流浏览器如IE、Netscape、Firefox、Opera等使用该技术。
Cookie保存在客户端（一般是浏览器），并根据其存储位置分为：内存式Cookie和硬盘式Cookie。其中，内存式Cookie存储在内存中，浏览器关闭后就会注销，因此也被称为非持久Cookie或会话Cookie；硬盘式Cookie存储在硬盘中，不会随浏览器的关闭而消失，除非用户手工清理或到达已设置的过期时间。由于硬盘式Cookie存储时间是长期的，因此也被称为持久Cookie。
以浏览器为例，内存式Cookie存储在document. Cookie中，该属性记录了当前打开网站的当前用户的Cookie。
不同客户端，持久化Cookie的存储位置不同。
在使用Session前，需要明确Session的应用上下文，避免出现歧义。计算机网络中，Session既可以指客户端与服务器之间一系列交互的动作，也可以指服务器端为客户端所开辟的保存客户端状态的存储空间。这里仅指后者。
如果说Cookie机制是通过检查客户身上的“通行证”来确定客户身份的话，那么Session机制就是通过检查服务器上的“客户明细表”来确认客户身份。Session相当于程序在服务器上建立的一份客户档案，客户来访的时候只需要查询客户档案表即可。
Session保存在服务器端。为了获得更高的存取速度，服务器一般把Session放在内存里。每个用户都会有一个独立的Session。如果Session内容过于复杂，当大量客户访问服务器时可能会导致内存溢出。因此，Session里的信息应该尽量精简。Session在用户第一次访问服务器时自动创建。Session生成后，只要用户继续访问，服务器就会更新Session的最后访问时间，并维护该Session。用户每访问服务器一次，无论是否读写Session，服务器都认为该用户的Session“活跃（active）”了一次。 由于会有越来越多的用户访问服务器，因此Session也会越来越多。为防止因用户过多，带来Session增加，从而导致内存溢出，服务器会把长时间内没有活跃的Session从内存删除。这个时间就是Session的超时时间。如果超过了超时时间，Session就自动失效了。
Cookie和Session都是会话跟踪技术的实现方案，用来跟踪用户的整个会话。但是Cookie和Session有以下区别：
(1) Cookie数据存放在客户的浏览器上，Session数据放在服务器上。
(2) 相比Session，Cookie更不安全，因为他人可以分析存放在本地的C’o’o’k’i’e并进行Cookie欺骗。考虑到安全，应使用Session或者使用加密技术对Cookie数据进行加密。
(3) Session默认仅在服务器保存一段时间。当访问增多，会比较占用你服务器的性能。考虑到减轻服务器性能方面，应当使用Cookie。
(4) 单个Cookie在客户端的限制是3K（也有说4K），就是说一个站点在客户端存放的Cookie不能超过3K；且Cookie的数量也有限制。
(5) 服务端Session的实现依赖客户端Cookie。服务端生成Session ID后，会将这个ID发送给客户端，然后客户端在后续的请求中都会把这个ID值放到HTTP请求的头部发送给服务端，而这个ID在客户端保存的常用容器就是Cookie。如果浏览器不支持Cookie或禁用Cookie，则需要使用其他机制（如URL重写机制，表单隐藏字段）代替Cookie暂存Session ID。

HTTPS协议

HTTPS（Hypertext Transfer Protocol over Secure Socket Layer，基于安全套接字层的超文本传输协议），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，通过 SSL证书来验证服务器的身份，并为浏览器和服务器之间的通信进行加密。其所用的端口号是443。

为什么使用HTTPS

HTTPS协议主要是为了解决HTTP协议存在的安全问题，使用HTTP协议传输，存在以下风险：
(1) 窃听⻛险，⽐如通信链路上可以获取通信内容，从而盗取用户账号。
(2) 篡改⻛险，⽐如强制植⼊垃圾⼴告，带来视觉污染。
(3) 冒充⻛险，⽐如冒充他人身份购物，导致用户金钱损失。

HTTPS原理

HTTPS就是在应用层和网络层补充了SSL/TSL。HTTP 的请求/响应一般可分为六步：(1) 建立TCP连接;(2) 发送HTTP请求;(3) 服务器处理请求;(4) 返回HTTP响应;(5) 释放TCP连接;(6) 浏览器解析返回的资源和数据。而，HTTPS是在完成TCP连接建立后，再补充一个SSL连接建立的过程，建立安全连接后，才是发送HTTP请求等后续事宜。接下来重点介绍下SSL建立连接(这里指TLS 1.2)的过程。

(1) 在 TCP 建立连接之后，浏览器会首先发一个"Client Hello"消息，也就是跟服务器“打招呼”。里面有客户端的版本号、支持的密码套件，还有一个随机数（Client Random）明文，用于后续生成会话密钥。
(2) 服务器收到"Client Hello"后，会返回一个"Server Hello"消息。把版本号对一下，也给出一个随机数（Server Random）明文，然后从客户端提供的密码套件列表里选一个作为本次通信使用的密码套件(如 ECDHE 算法)。同时，服务器为了证明自己的身份，就把证书(Server Certificate)也发给了客户端。因为服务器已经选择了密码套件，所以它会在证书后发送"Server Key Exchange"消息，里面是公钥（Server Params），用来实现密钥交换算法，再加上自己的私钥签名认证。
之后是“Server Hello Done”消息，表示"打招呼完毕"。这样第一个消息往返就结束了(两个 TCP 包)，结果是客户端和服务器通过明文共享了三个信息：Client Random、Server Random 和 Server Params。
(3) 浏览器拿到服务器的证书后，开始确认证书的真实性，用证书公钥验证签名。确认服务器身份后，浏览器根据已选择的密码套件，生成一个公钥（Client Params），然后用"Client Key Exchange"消息发给服务器。现在浏览器和服务器手里都拿到了密钥交换算法的两个参数（Client Params、Server Params），接着就用密码套件算法，算出"Pre-Master"。现在浏览器和服务器手里有了三个随机数：Client Random、Server Random 和 Pre-Master。用这三个作为原始材料，就可以生成用于加密会话的主密钥，叫"Master Secret"。而黑客因为拿不到"Pre-Master"，所以也就得不到主密钥。
为什么需要Client Random、Server Random 和 Pre-Master 三个随机数？这主要是因为，TLS 协议不信任浏览器或服务器伪随机数的可靠性，为了保证真正的"完全随机"、“不可预测”，就把三个不可靠的随机数混合起来，那么"随机"的程度就更高了，安全性也就更有保障。
有了主密钥和基于主密钥派生的会话密钥(Session Secret)，握手就快结束了。浏览器发送一个"Change Cipher Spec"消息，然后再发送一个"Finished"消息，把之前所有发送的数据做个摘要，再加密一下，让服务器做个验证。
(4) 服务器接收到浏览器的验证请求后，按照相同的步骤，分别发送"Change Cipher Spec"和"Finished"消息。
(5) 完成上述操作后，TSL连接就建立完成了，接下来就是通过加密的方式来发送HTTP请求和响应。

HTTPS缺点

HTTPS协议具有以下缺点：
(1) HTTPS协议多次握手，导致页面的加载时间延长近50%。
(2) HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗。
(3) 申请SSL证书需要钱，功能越强大的证书费用越高。
(4) SSL涉及到的安全算法会消耗 CPU 资源，对服务器资源消耗较大。

HTTP 与 HTTPS 的区别

HTTP 是超⽂本传输协议，信息是明⽂传输，存在安全⻛险的问题。HTTPS 则解决 HTTP 不安全的缺陷，在TCP 和 HTTP ⽹络层之间加⼊了 SSL/TLS 安全协议，使得报⽂能够加密传输。
HTTP 连接建⽴相对简单， TCP 三次握⼿之后便可进⾏ HTTP 的报⽂传输。⽽ HTTPS 在 TCP 三次握⼿之后，还需进⾏ SSL/TLS 的握⼿过程，才可进⼊加密报⽂传输。
HTTP 的端⼝号是 80，HTTPS 的端⼝号是 443。
HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

参考

《计算机网络（第五版）》 谢希仁编著
《TCP/IP详解 卷1：协议》 W.Richard Stevens 著，范建华 等译
https://blog.csdn.net/adminpd/article/details/122973684 计算机网络面试题总结（2022最新版）
https://zhuanlan.zhihu.com/p/466239718 【转】面试必备：计算机网络常问的六十二个问题（建议收藏）
https://zhuanlan.zhihu.com/p/60305452 计算机网络面试题（一）
https://zhuanlan.zhihu.com/p/138272238 计算机网络面试题（含答案）
https://zhuanlan.zhihu.com/p/471948799 计算机网络面试题（含解答）2022版
https://zhuanlan.zhihu.com/p/531820908 计算机网络面试题
https://blog.csdn.net/qq_42651904/article/details/91355804 计算机网络面试题总结
https://blog.csdn.net/qq_38289815/article/details/80969419 HTTP 和 HTTPS 的区别
https://blog.csdn.net/weixin_43604162/article/details/106967376 【计算机网络】整体结构——2.计算机网络体系结构、参考模型
https://subscription.packtpub.com/book/cloud-and-networking/9781789340501/1/ch01lvl1sec11/the-tcp-ip-protocol-suite The tcp-ip protocol suite
https://blog.csdn.net/CN_TangZheng/article/details/102476750 快速理解OSI七层模型（举例理解，数据传输过程，深入理解OSI七层模型）
https://zhuanlan.zhihu.com/p/350408610 计算机网络的七层结构、五层结构和四层结构
https://www.leeks.info/zh_CN/latest/Linux_Notes/tcpip/tcpip-basics.html TCP/IP 基础
https://dikapedia.com/wiki/index.php/OSI_Model_&_TCP/IP_Model OSI Model & TCP/IP Model
https://zhuanlan.zhihu.com/p/441680495 TCP/IP 与 OSI：两种模型之间的区别是什么？
https://zhuanlan.zhihu.com/p/153515394 10张图带你搞懂数据链路层PPP点到点协议
https://blog.csdn.net/HinsCoder/article/details/130781224 【网络协议详解】——PPP协议（学习笔记）
https://tools.ietf.org/html/rfc2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms