计算机网络概念

网络协议

在计算机网络要做到有条不紊地交换数据，就必须遵守一些事先约定好的规则，比如交换数据的格式、是否需要发送一个应答信息。这些规则被称为网络协议。

计算机网络体系结构

计算机网络体系结构是指计算机网络层次结构模型，它是各层的协议以及层次之间的端口的集合。在计算机网络中实现通信必须依靠网络通信协议，目前广泛采用的是国际标准化组织（ISO）1997年提出的开放系统互联（Open System Interconnection，OSI）参考模型，习惯上称为ISO/OSI参考模型。

不同的网络体系结构

OSI七层协议体系结构

OSI 的七层协议体系结构的概念清楚，理论也较完整，但它既复杂又不实用。

OSI七层协议模型主要包括是：

应用层（Application）
表示层（Presentation）
会话层（Session）
运输层（Transport）
网络层（Network）
数据链路层（Data Link）
物理层（Physical）

TCP/IP四层体系结构

TCP/IP 是一个四层体系结构，主要包括：

应用层
运输层
网际层（用网际层这个名字是强调这一层是为了解决不同网络的互连问题）
网络接口层

不过从实质上讲，TCP/IP 只有最上面的三层，因为最下面的网络接口层并没有什么具体内容，因此在学习计算机网络的原理时往往采用折中的办法，即综合 OSI 和 TCP/IP 的优点，采用一种只有五层协议的体系结构。

五层协议的体系结构

五层协议的体系结构主要包括：

应用层
运输层
网络层
数据链路层
物理层

ps. 五层协议的体系结构只是为了介绍网络原理而设计的，实际应用还是 TCP/IP 四层体系结构。

TCP/IP

具有五层协议的体系结构

应用层

应用层（application-layer）的任务是通过应用进程间的交互来完成特定网络应用。应用层协议定义的是应用进程（进程：主机中正在运行的程序）间的通信和交互的规则。

运输层

运输层（transport layer）的主要任务就是负责向两台主机进程之间的通信提供通用的数据传输服务。应用进程利用该服务传送应用层报文。

运输层主要使用一下两种协议

TCP-传输控制协议：提供面向连接的，可靠的数据传输服务
UDP-用户数据协议：提供无连接的，尽最大努力的数据传输服务（不保证数据传输的可靠性）

每一个应用层（TCP/IP参考模型的最高层）协议一般都会使用到两个传输层协议之一

ps. 以下协议是应用层协议：

运行在TCP协议上的协议：

HTTP（Hypertext Transfer Protocol，超文本传输协议），主要用于普通浏览。端口号：80
HTTPS（HTTP over SSL，安全超文本传输协议）,HTTP协议的安全版本。端口号：443
FTP（File Transfer Protocol，文件传输协议），用于文件传输。端口号：21
POP3（Post Office Protocol, version 3，邮局协议），收邮件用。
SMTP（Simple Mail Transfer Protocol，简单邮件传输协议），用来发送电子邮件。
TELNET（Teletype over the Network，网络电传），通过一个终端（terminal）登陆到网络。端口号：23
SSH（Secure Shell，用于替代安全性差的TELNET），用于加密安全登陆用。

运行在UDP协议上的协议：

BOOTP（Boot Protocol，启动协议），应用于无盘设备。
NTP（Network Time Protocol，网络时间协议），用于网络同步。
DHCP（Dynamic Host Configuration Protocol，动态主机配置协议），动态配置IP地址。

运行在TCP和UDP协议上：

DNS（Domain Name Service，域名服务），用于完成地址查找，邮件转发等工作。

网络层（网际层）

网络层负责为分组交换网上的不同主机提供通信服务。在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送。在 TCP/IP 体系结构中，由于网络层使用 IP 协议，因此分组也叫 IP 数据报，简称数据报。

互联网是由大量的异构（heterogeneous）网络通过路由器（router）相互连接起来的。互联网使用的网络层协议是无连接的网际协议（Intert Prococol）和许多路由选择协议，因此互联网的网络层也叫做网际层或 IP 层。

数据链路层

数据链路层(data link layer)通常简称为链路层。两台主机之间的数据传输，总是在一段一段的链路上传送的，这就需要使用专门的链路层的协议。

在两个相邻节点之间传送数据时，数据链路层将网络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。每一帧包括数据和必要的控制信息（如同步信息，地址信息，差错控制等）。

物理层

在物理层上所传送的数据单位是比特。

数据传输过程

TCP的三次握手四次挥手

三次握手

四次挥手

MSL是Maximum Segment Lifetime英文的缩写，中文可以译为“报文最大生存时间”，他是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。

CLOSED：表示初始状态。
LISTEN：该状态表示服务器端的某个SOCKET处于监听状态，可以接受连接。
SYN_SENT：这个状态与SYN_RCVD遥相呼应，当客户端SOCKET执行CONNECT连接时，它首先发送SYN报文，随即进入到了SYN_SENT状态，并等待服务端的发送三次握手中的第2个报文。SYN_SENT状态表示客户端已发送SYN报文。
SYN_RCVD: 该状态表示接收到SYN报文，在正常情况下，这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态，很短暂。此种状态时，当收到客户端的ACK报文后，会进入到ESTABLISHED状态。
ESTABLISHED：表示连接已经建立。
FIN_WAIT_1: FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。区别是：FIN_WAIT_1状态是当socket在ESTABLISHED状态时，想主动关闭连接，向对方发送了FIN报文，此时该socket进入到FIN_WAIT_1状态。FIN_WAIT_2状态是当对方回应ACK后，该socket进入到FIN_WAIT_2状态，正常情况下，对方应马上回应ACK报文，所以FIN_WAIT_1状态一般较难见到，而FIN_WAIT_2状态可用netstat看到。
FIN_WAIT_2：主动关闭链接的一方，发出FIN收到ACK以后进入该状态。称之为半连接或半关闭状态。该状态下的socket只能接收数据，不能发。
TIME_WAIT: 表示收到了对方的FIN报文，并发送出了ACK报文，等2MSL后即可回到CLOSED可用状态。如果FIN_WAIT_1状态下，收到对方同时带 FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。
CLOSING: 这种状态较特殊，属于一种较罕见的状态。正常情况下，当你发送FIN报文后，按理来说是应该先收到（或同时收到）对方的 ACK报文，再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢？如果双方几乎在同时close一个SOCKET的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态，表示双方都正在关闭SOCKET连接。
CLOSE_WAIT: 此种状态表示在等待关闭。当对方关闭一个SOCKET后发送FIN报文给自己，系统会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，察看是否还有数据发送给对方，如果没有可以 close这个SOCKET，发送FIN报文给对方，即关闭连接。所以在CLOSE_WAIT状态下，需要关闭连接。
LAST_ACK: 该状态是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，即可以进入到CLOSED可用状态。

半关闭状态

为什么TCP连接的时候是3次，不是2次

因为需要考虑连接时丢包的问题，如果只握手2次，第二次握手时如果服务端发给客户端的确认报文段丢失，此时服务端已经准备好了收发数(可以理解服务端已经连接成功)据，而客户端一直没收到服务端的确认报文，所以客户端就不知道服务端是否已经准备好了(可以理解为客户端未连接成功)，这种情况下客户端不会给服务端发数据，也会忽略服务端发过来的数据。

如果是三次握手，即便发生丢包也不会有问题，比如如果第三次握手客户端发的确认ack报文丢失，服务端在一段时间内没有收到确认ack报文的话就会重新进行第二次握手，也就是服务端会重发SYN报文段，客户端收到重发的报文段后会再次给服务端发送确认ack报文。

为什么连接的时候是三次握手，关闭的时候却是四次握手？

因为只有在客户端和服务端都没有数据要发送的时候才能断开TCP。客户端发出FIN报文时只能保证客户端没有数据发了，服务端还有没有数据发客户端是不知道的。而服务端收到客户端的FIN报文后只能先回复客户端一个确认报文来告诉客户端我服务端已经收到你的FIN报文了，但我服务端还有一些数据没发完，等这些数据发完了服务端才能给客户端发FIN报文（所以不能一次性将确认报文和FIN报文发给客户端，就是这里多出来了一次）。

为什么客户端发出第四次挥手的确认报文后要等2MSL的时间才能释放TCP连接？

这里同样是要考虑丢包的问题，如果第四次挥手的报文丢失，服务端没收到确认ack报文就会重发第三次挥手的报文，这样报文一去一回最长时间就是2MSL，所以需要等这么长时间来确认服务端确实已经收到了。

如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP设有一个保活计时器，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

TCP和UDP对比

	UPD	TCP
是否连接	无连接	面向连接（3次握手）
是否可靠	尽最大努力交付，不保证可靠。不使用流量控制和拥塞控制	使用流量控制和拥塞控制。可靠服务：无差错、不丢失、不重复、按序到达
传输方式	面向报文	面向字节流
连接对象个数	一对一，多对多，多对一，一对多	一对一
首部开销	8字节	首部最小20字节，最大60字节

TCP怎么保证可靠

应用数据被分割成 TCP 认为最适合发送的数据块。
TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
校验和：TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。
TCP 的接收端会丢弃重复的数据。
流量控制：TCP 连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。（TCP 利用滑动窗口实现流量控制）
拥塞控制：当网络拥塞时，减少数据的发送。
ARQ协议：也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。
超时重传：当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

拥塞控制和流量控制

都是保证TCP可靠的方法。

拥塞控制：拥塞控制是作用于网络的，它是防止过多的数据注入到网络中，避免出现网络负载过大的情况
流量控制：流量控制是作用于接收者的，它是控制发送者的发送速度从而使接收者来得及接收，防止分组丢失的

拥塞控制

慢开始：从小到大逐渐增大发送窗口，每个传输轮次后将 cwnd 大小加倍。
拥塞避免：用慢开始门限（ssthresh）的阈值来控制 cwnd 的增长
- cwnd < ssthresh , 使用慢开始算法
- cwnd = ssthresh , 使用慢开始算法或拥塞避免算法（线性增长，一般是加1）都可以
- cwnd > ssthresh , 使用拥塞避免算法。只要发现网络中出现拥塞就乘法减小ssthresh并从cwnd=1开始重新执行慢开始算法。
快重传：允许发送方再连续收到 3 个重复的确认后就可以开始执行乘法减小过程而不必再等待所设置的重传计时器到时。
快恢复：是与快重传算法配合使用的一个算法。快恢复算法后与原来不同的一点是当发现网络出现拥塞并执行了乘法减小过程后，并不是设置cwnd=1并重新开始执行慢开始算法，而是让 cwnd =乘法减小后的ssthresh并开始执行拥塞避免算法。

ps. ssthresh的设置：TCP/IP 中规定无论是在慢开始阶段还是在拥塞避免阶段，只要发现网络中出现拥塞（没有按时收到确认），就要把ssthresh设置为此时发送窗口的一半大小（不能小于2）

TCP的拥塞控制（详解）

流量控制

RTT算法
滑动窗口
- 发送窗口
- 接受窗口

使UPD可靠的方法

超时重传（定时器）
有序接受（添加包序号）
应答确认（Seq/Ack应答机制）
滑动窗口流量控制等机制（滑动窗口协议）

已有协议：

可靠用户数据报协议（RUDP）：RUDP使用类似于TCP的重发机制和拥塞控制算法
实时协议（RTP）：有效负载识别，序列编号，时间戳和投递监听
基于UDP的数据传输协议（UDT）：序列号、滑动窗口

为什么会发生 TCP 粘包、拆包

粘包问题是由TCP是“字节流”协议，没有消息边界所引起的。

应用程序写入的数据大于套接字缓冲区大小，这将会发生拆包。
应用程序写入数据小于套接字缓冲区大小，网卡将应用多次写入的数据发送到网络上，这将会发生粘包。
进行 MSS （最大报文长度）大小的 TCP 分段，当 TCP报文长度 - TCP头部长度 > MSS 的时候将发生拆包。
接收方法不及时读取套接字缓冲区数据，这将发生粘包。

如何处理粘包、拆包？

解决粘包的方法就是由应用层进行分包处理，本质上就是由应用层来维护消息和消息的边界。

使用带消息头的协议、消息头存储消息开始标识及消息长度信息，服务端获取消息头的时候解析出消息长度，然后向后读取该长度的内容。
设置定长消息，服务端每次读取既定长度的内容作为一条完整消息，当消息不够长时，空位补上固定字符。
设置消息边界，服务端从网络流中按消息编辑分离出消息内容，一般使用‘\n’。
更为复杂的协议。

简述Socket通信基本步骤

具体分成两个部分：

服务端
- socket(创建socket)
- bind(绑定socket和端口号)
- listen(监听该端口号)
- accept(等待并接受客户端连接请求)
- read,write(读取数据和返回数据)
- close(关闭socket)
客户端
- socket(创建socket)
- connect(连接指定的端口)
- read,write(读取数据和返回数据)
- close(关闭socket)

GET、POST的区别

作用
GET 用于获取资源，而 POST 用于传输数据。
参数
GET 和 POST 的请求都能使用额外的参数，但是 GET 的参数是以查询字符串出现在 URL 中，而 POST 的参数存储在实体主体中。
安全
GET 方法是安全的，而 POST 却不是。安全就是说请求方法不会改变服务器状态，也就是说它只是可读的。因为 POST 的目的是传送数据，这个数据可能是用户上传的表单，上传成功之后，服务器可能把这个数据存储到数据库中，因此状态也就发生了改变。所以，从这个方面来讲，POST是不安全的。
幂等
GET方法都是幂等的，但 POST 方法不是。幂等就是说，同样的请求被执行一次与连续执行多次的效果是一样的，服务器的状态也是一样的。所以，幂等方法不应该具有副作用。

HTTP与HTTPS的区别

https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

HTTPS是运行在SSL/TLS之上的HTTP协议，SSL/TLS 运行在TCP之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS高，但是 HTTPS 比HTTP耗费更多服务器资源。

SSL四次握手

客户端请求建立SSL链接，并向服务端发送一个随机数–Client random和客户端支持的加密方法，比如RSA公钥加密，此时是明文传输。
服务端回复一种客户端支持的加密方法、一个随机数–Server random、授信的服务器证书和非对称加密的公钥。
客户端收到服务端的回复后利用服务端的公钥，加上新的随机数–Premaster secret 通过服务端下发的公钥及加密方法进行加密，发送给服务器。
服务端收到客户端的回复，利用已知的加解密方式进行解密，同时利用Client random、Server random和Premaster secret通过一定的算法生成HTTP链接数据传输的对称加密key – session key。

什么是对称加密与非对称加密

对称加密：密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密算法有DES、AES等。这种方式存在的最大问题就是密钥发送问题，即如何安全地将密钥发给对方；
非对称加密：密钥成对出现（且根据公钥无法推知私钥，根据私钥也无法推知公钥），加密解密使用不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢，典型的非对称加密算法有RSA、DSA等。

ref

详细解析HTTP 与HTTPS 的区别

HTTPS工作原理

首先HTTP请求服务端生成证书，客户端对证书的有效期、合法性、域名是否与请求的域名一致、证书的公钥（RSA加密）等进行校验；
客户端如果校验通过后，就根据证书的公钥的有效，生成随机数，随机数使用公钥进行加密（RSA加密）；
消息体产生的后，对它的摘要进行MD5（或者SHA1）算法加密，此时就得到了RSA签名；
发送给服务端，此时只有服务端（RSA私钥）能解密。
解密得到的随机数，再用AES加密，作为密钥（此时的密钥只有客户端和服务端知道）。

HTTP长连接，短连接是什么？

HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。

在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源（如JavaScript文件、图像文件、CSS文件等），每遇到这样一个Web资源，浏览器就会重新建立一个HTTP会话。

而从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加入这行代码：Connection:keep-alive

在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。

HTTP版本对比

HTTP1.0版本的特性：

1.0的HTTP版本，是一种无状态、无连接的应用层协议。
HTTP1.0规定浏览器和服务器保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器处理完成后立即断开TCP连接（无连接），服务器不跟踪每个客户端也不记录过去的请求（无状态）。

HTTP1.1版本新特性

默认持久连接节省通信量，只要客户端服务端任意一端没有明确提出断开TCP连接，就一直保持连接，可以发送多次HTTP请求
管线化，客户端可以同时发出多个HTTP请求，而不用一个个等待响应
断点续传原理

HTTP2.0版本的特性

二进制分帧（采用二进制格式的编码将其封装）
首部压缩（设置了专门的首部压缩设计的HPACK算法。）
流量控制（设置了接收某个数据流的多少字节一些流量控制）
多路复用（可以在共享TCP链接的基础上同时发送请求和响应）
请求优先级（可以通过优化这些帧的交错和传输顺序进一步优化性能）
服务器推送（就是服务器可以对一个客户端请求发送多个响应。服务器向客户端推送资源无需客户端明确的请求。（重大更新））

HTTP1.1 和 HTTP2.0 的区别

新的二进制格式（Binary Format），HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。
多路复用（MultiPlexing），即连接共享，即每一个request都是是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。
header压缩，如上文中所言，对前面提到过HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。
服务端推送（server push），同SPDY一样，HTTP2.0也具有server push功能。

ref. HTTP1.0、HTTP1.1 和 HTTP2.0 的区别

输入URL到显示网页的过程

DNS解析：简单地说就是找到URL对应的IP地址。
TCP连接：浏览器与目标服务器建立TCP连接
- HTTP协议建立在TCP协议之上，HTTP请求前，需先进行TCP连接，形成客户端到服务器的稳定的通道。俗称TCP的三次握手。
- TCP连接完成后，HTTP请求开始，请求有多种方式，常见的有GET，POST等。
发送HTTP请求
- HTTP请求包含请求头，也可能包含请求体两部分，请求头中包含我们希望对请求文件的操作的信息，请求体中包含传递给后台的参数。
服务器处理请求并返回HTTP报文
- 服务器收到HTTP请求后，后台开始工作，如负载平衡，跨域等，这里就是后端的工作了。
- 文件处理完毕，生成响应数据包，响应也包含两部分，响应头和相应体，响应体就是我们所请求的文件。
- 经过网络传输，文件被下载到本地客户端，客户端开始加载。
浏览器解析渲染HTML页面
- 客户端浏览器加载了HTML文件后，由上到下解析HTML为DOM树（DOM Tree）。
- 遇到CSS文件，CSS中的url发起HTTP请求。
- 这是第二次HTTP请求，由于HTTP1.1协议增加了Connection: keep-alive声明，故TCP连接不会关闭，可以复用。
- HTTP连接是无状态连接，客户端与服务器端需要重新发起请求–响应。在请求CSS的过程中，解析器继续解析HTML，然后到了script标签。
- 由于script可能会改变DOM结构，故解析器停止生成DOM树，解析器被js阻塞，等待js文件发起HTTP请求，然后加载。这是第三次HTTP请求。js执行完成后解析器继续解析。
- 由于CSS文件可能会影响js文件的执行结果，因此需等CSS文件加载完成后再执行。
- 浏览器收到CSS文件后，开始解析CSS文件为CSSOM树（CSS Rule Tree）。
- CSSOM树生成后，DOM Tree与CSS Rule Tree结合生成渲染树（Render Tree）。
- Render Tree会被CSS文件阻塞，渲染树生成后，先布局，绘制渲染树中节点的属性(位置，宽度，大小等)，然后渲染，页面就会呈现信息。
- 继续边解析边渲染，遇到了另一个js文件，js文件执行后改变了DOM树，渲染树从被改变的dom开始再次渲染。
- 继续向下渲染，碰到一个img标签，浏览器发起HTTP请求，不会等待img加载完成，继续向下渲染，之后再重新渲染此部分。
- DOM树遇到HTML结束标签，停止解析，进而渲染结束。
连接结束

涉及到的协议：IP(网络)、OSPF(路由)、ARP(本地MAC解析)

ARP，RARP 和 ICMP

ARP协议：属于ipv4协议簇，工作在数据链路层。其功能是把网络层32位的IP转换成数据链路层48位的MAC地址，在这个过程中有一个很重要的表——ARP缓存表，
- ARP缓存表中缓存了IP地址和MAC地址的映射关系。如果没有缓存的情况，ARP会广播某一个IP的信息，收到这个广播的设备会回应一个包，表示我是不是这个IP地址。如果是，广播该IP地址的设备会记录对应设备的MAC地址。
RARP协议:(reverse arp，反向arp协议)，和ARP协议做相反的工作，它将48位的MAC地址转换为32位的IP地址。
ICMP协议:（Internet Control Message Protocol，网络控制消息协议），它的功能是报告无法传送的数据包的错误，并帮助对这些错误进行疑难解答。

DNS(Domain Name System, 域名系统) 域名解析过程

域名格式：三级域名.二级域名.顶级域名(www.baidu.com)

域名服务器：保存域名到IP地址映射的服务器。

递归查询：主机向本地域名服务器的查询一般都是采用递归查询。指的是，当主机所询问的本地域名服务器不知道被查询的域名IP地址时，本地域名服务器就以DNS客户的身份，向其他根域名服务器继续查询，而不是让主机自己进行下一步查询，
迭代查询：本地域名服务器向根域名服务器查询通常采用迭代查询。指的是，当根域名服务器没有保存本地域名服务器所查询的域名IP地址时，就告诉本地域名服务器下一步应当找哪一个域名服务器查询，而不是根域名服务器以客户身份查询。

找域名服务器查询之前，会先找缓存中有没有：

浏览器缓存：当用户通过浏览器访问某域名时，浏览器首先会在自己的缓存中查找是否有该域名对应的IP地址（若曾经访问过该域名且没有清空缓存便存在）
系统缓存：当浏览器缓存中无域名对应IP则会自动检查用户计算机系统Hosts文件DNS缓存是否有该域名对应IP
路由器缓存：当浏览器及系统缓存中均无域名对应IP则进入路由器缓存中检查

当以上三个缓存中都没有，才会向DNS服务器查询。

NAT(Network Address Translation, 网络地址转换)协议

用于解决内网中的主机要和因特网上的主机通信。由NAT路由器将主机的本地IP地址转换为全球IP地址，分为静态转换（转换得到的全球IP地址固定不变）和动态NAT转换。

cookie和session对于HTTP有什么用？

HTTP协议本身是无法判断用户身份。所以需要cookie或者session

什么是cookie

cookie是由Web服务器保存在用户浏览器上的文件（key-value格式），可以包含用户相关的信息。客户端向服务器发起请求，就提取浏览器中的用户信息由http发送给服务器

什么是session

session 是浏览器和服务器会话过程中，服务器会分配的一块储存空间给session。

服务器默认为客户浏览器的cookie中设置 sessionid，这个sessionid就和cookie对应，浏览器在向服务器请求过程中传输的cookie 包含 sessionid ，服务器根据传输cookie 中的 sessionid 获取出会话中存储的信息，然后确定会话的身份信息。

cookie与session区别

cookie数据存放在客户端上，安全性较差，session数据放在服务器上，安全性相对更高
单个cookie保存的数据不能超过4K，session无此限制
session一定时间内保存在服务器上，当访问增多，占用服务器性能，考虑到服务器性能方面，应当使用cookie。

Reference

谢希仁. 计算机网络（第7版）. 电子工业出版社
重学TCP/IP协议和三次握手四次挥手
TCP/UDP区别以及UDP如何实现可靠传输