[网络协议]计算机网络面经

一、计算机网络分层结构是什么？

计算机网络体系大致分为三种，OSI七层模型，TCP/IP 四层模型和五层模型。一般面试都是考察五层模型。

TCP/IP五层模型：应用层、传输层、网络层、数据链路层、物理层。（重要）

1. 应用层：为应用程序提供交互服务。在互联网中的应用层协议很多，如域名系统DNS、HTTP协议、SMTP协议等
2. 传输层：负责向两台主机进程之间的通信提供数据传输服务。传输层的协议主要有传输控制协议TCP和用户数据协议UDP
3. 网络层：选择合适的路由和交换节点，确保数据及时传输，主要包括IP协议。
4. 数据链路层：在两个相邻节点之间传送数据时，数据链路层将网络层交下来的IP数据报组装成帧，在两个相邻节点间的链路上传送帧。
5. 物理层：实现相邻节点间比特流的透明传输，尽可能屏蔽传输介质和物理设备的差异。

二、三次握手（重要）

假设发送端为客户端，接收端为服务端。开始时客户端和服务端的状态都是 CLOSED 。

序列号seq：占4个字节，用来标记数据段的顺序，TCP把连接中发送的所有数据字节都编上一个序号，第一个字节的编号由本地随机产生；给字节编上序号后，就给每一个报文段指派一个序号；序列号seq就是这个报文段中的第一个字节的数据编号。

确认号ack：占4个字节，期待收到对方下一个报文段的第一个数据字节的序号；序列号表示报文段携带数据的第一个字节的编号；而确认号指的是期望接收到下一个字节的编号；因此当前报文段最后一个字节的编号+1即为确认号。

确认ACK：占1位，仅当ACK=1时，确认号字段才有效。ACK=0时，确认号无效

同步SYN：连接建立时用于同步序号。当SYN=1，ACK=0时表示**：这是一个连接请求报文段**。若同意连接，则在响应报文段中使得SYN=1，ACK=1。因此，SYN=1表示这是一个连接请求，或连接接受报文。SYN这个标志位只有在TCP建产连接时才会被置1，握手完成后SYN标志位被置0。

终止FIN：用来释放一个连接。FIN=1表示：此报文段的发送方的数据已经发送完毕，并要求释放运输连接

PS：ACK、SYN和FIN这些大写的单词表示标志位，其值要么是1，要么是0；ack、seq小写的单词表示序号。

1. 第一次握手：客户端向服务端发起建立连接的请求，客户端会随机生成一个起始序列号x，客户端向服务端发送的字段中包含标志位SYN=1，序列号seq=x，第一次握手前客户端的状态为close，第一次握手后客户端的状态为SYN-SENT。此时服务端的状态为Listen。
2. 第二次握手：服务端在收到客户端发来的报文后，会随机生成一个服务端的起始序列号y，然后给客户端回复一段报文，其中包括标志位SYN=1,ACK=1,序列号seq=y，确认号ack=x+1，第二次握手前服务端的状态为 LISTEN ，第二次握手后服务端的状态为 SYN-RCVD ，此时客户端的状态为 SYN-SENT 。（其中 SYN=1 表示要和客户端建立一个连接， ACK=1 表示确认序号有效）
3. 第三次握手：客户端收到服务端发来的报文后，会再向服务端发送报文，其中包含标志位 ACK=1 ，序列号 seq=x+1 ，确认号 ack=y+1 。第三次握手前客户端的状态为 SYN-SENT ，第三次握手后客户端和服务端的状态都为 ESTABLISHED 。此时连接建立完成。

三、两次握手可以吗？

第三次握手主要为了防止已失效的连接请求报文段突然又传输到了服务端，导致产生问题。

1. 比如客户端A发出连接请求，可能因为网络阻塞原因，A没有收到确认报文，于是A再重传一次连接请求。
2. 连接成功，等待数据传输完毕后，就释放了连接。
3. 然后A发出的第一个连接请求等到连接释放以后的某个时间才到达服务端B，此时B误认为A又发出一次新的连接请求，于是就向A发出确认报文段。
4. 如果不采用三次握手，只要B发出确认，就建立新的连接了，此时A不会响应B的确认且不发送数据，则B一直等待A发送数据，浪费资源。

四、四次挥手（重要）

1. A的应用进程先向其TCP发出连接释放报文段（ FIN=1，seq=u ），并停止再发送数据，主动关闭TCP连接，进入 FIN-WAIT-1 （终止等待1）状态，等待B的确认。
2. B收到连接释放报文段后即发出确认报文段（ ACK=1，ack=u+1，seq=v ），B进入 CLOSE-WAIT（关闭等待）状态，此时的TCP处于半关闭状态，A到B的连接释放。
3. A收到B的确认后，进入 FIN-WAIT-2 （终止等待2）状态，等待B发出的连接释放报文段。
4. B发送完数据，就会发出连接释放报文段（ FIN=1，ACK=1，seq=w，ack=u+1 ），B进入 LAST-ACK（最后确认）状态，等待A的确认。
5. A收到B的连接释放报文段后，对此发出确认报文段（ ACK=1，seq=u+1，ack=w+1 ），A进入 TIME- WAIT （时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间 2MSL （最大报文段生存时间）后，A才进入 CLOSED 状态。B收到A发出的确认报文段后关闭连接，若没收到A发出的确认报文段，B就会重传连接释放报文段。

五、第四次挥手为什么要等待2MSL？

说明什么是MSL，MSL是Maximum Segment Lifetime的缩写，译为报文最大生存时间，也就是任何报文在网络上存活的最大时间，一旦超过该时间，报文就会被丢弃。2MSL也就是指的2倍MSL的时间

1. 保证A发送的最后一个ACK报文段能够到达B。这个 ACK 报文段有可能丢失，B收不到这个确认报文，就会超时重传连接释放报文段，然后A可以在 2MSL 时间内收到这个重传的连接释放报文段，接着A重传一次确认，重新启动2MSL计时器，最后A和B都进入到 CLOSED 状态，若A在 TIME-WAIT 状态不等待一段时间，而是发送完ACK报文段后立即释放连接，则无法收到B重传的连接释放报文段，所以不会再发送一次确认报文段，B就无法正常进入到 CLOSED 状态。
2. 防止已失效的连接请求报文段出现在本连接中。A在发送完最后一个 ACK 报文段后，再经过2MSL，就可以使这个连接所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现旧的连接请求报文段。

简短回答：

1. 保证客户端发送的最后一个确认报文到达服务端，如果丢失，可以在服务端等待超时重传FIN报文，客户端接收到FIN报文后重传确认报文。
2. 使本次连接过程中产生的所有报文段从网络中消失，防止已失效的连接请求报文出现。

为什么是2MSL?
所以被动关闭的B无需任何wait time，直接释放资源。
但A并不知道B是否接到自己的ACK，A是这么想的：
1）如果B没有收到自己的ACK，会超时重传FiN那么A再次接到重传的FIN，会再次发送ACK
2）如果B收到自己的ACK，也不会再发任何消息，包括ACK
无论是1还是2，A都需要等待，要取这两种情况等待时间的最大值，以应对最坏的情况发生，这个最坏情况是：
去向ACK消息最大存活时间（MSL) + 来向FIN消息的最大存活时间(MSL)。这恰恰就是2MSL( Maximum Segment Life)。
等待2MSL时间，A就可以放心地释放TCP占用的资源、端口号，此时可以使用该端口号连接任何服务器。同时也能保证网络中老的链接全部消失。

TIME_WAIT 过多有什么危害？
过多的 TIME-WAIT 状态主要的危害有两种：

1. 第一是内存资源占用；
2. 第二是对端口资源的占用，一个 TCP 连接?少消耗?个本地端口；

六、为什么是四次挥手？

因为当Server端收到Client端的 SYN 连接请求报文后，可以直接发送 SYN+ACK 报文。但是在关闭连接时，当Server端收到Client端发出的连接释放报文时，很可能并不会立即关闭SOCKET，所以Server端先回复一个 ACK 报文，告诉Client端我收到你的连接释放报文了。只有等到Server端所有的报文都发送完了，这时Server端才能发送连接释放报文，之后两边才会真正的断开连接。故需要四次挥手。

七、TCP协议

7.1 TCP有哪些特点？

1. TCP提供一种面向连接的、可靠的字节流服务。
2. 在一个TCP连接服务中，仅有两方进行彼此通信。广播和多播不能用于TCP。
3. TCP使用检验和，确认和重传机制来保证可靠传输。
4. TCP给数据分节进行排序，并使用累计确认保证数据的顺序不变和非重复。
5. TCP使用滑动窗口机制来实现流量控制，通过动态改变窗口的大小进行拥塞控制。

7.2 TCP如何保证传输的可靠性？

1. 数据包校验
2. 对失序数据包重新排序（TCP报文具有序列号）
3. 丢弃重复数据
4. 确认机制：接收方收到数据之后，会发送一个确认（通常延迟几分之一秒）；
5. 超时重发：发送方发出数据之后，启动一个定时器，超时未收到接收方的确认，则重新发送这个数据；
6. 流量控制：确保接收端能够接收发送方的数据而不会缓冲区溢出

7.3 TCP的流量控制？

1. 流量控制是为了控制发送方的发送速率，保证接收方来得及接收；
2. 接收方维护一个接收窗口，大小根据资源情况动态调整，接收方发送的确认报文中的窗口字段可用来控制发送方的发送窗口大小，从而影响发送方的发送速率。
3. 发送窗口的上限为接受窗口和拥塞窗口中的较小值。接受窗口表明了接收方的接收能力，拥塞窗口表明了网络的传送能力。

7.4 TCP 三次握手能否携带数据？

第三次是可以携带数据的。

假如第一次握手可以携带数据的话，如果恶意攻击服务器，每次都在第一次握手中的SYN报文中放入大量数据。而且频繁重复发SYN报文，服务器会花费很多的时间和内存空间去接收这些报文。

第三次握手，此时客户端已经处于ESTABLISHED状态。对于客户端来说，他已经建立起连接了，并且已经知道服务器的接收和发送能力是正常的。所以也就可以携带数据了。

7.5 三次握手连接阶段，最后一次ACK包丢失，会发生什么？

服务端：
第三次的ACK在网络中丢失，那么服务端该TCP连接的状态为SYN_RECV,并且会根据 TCP的超时重传机制，会等待3秒、6秒、12秒后重新发送SYN+ACK包，以便客户端重新发送ACK包。 如果重发指定次数之后，仍然未收到 客户端的ACK应答，那么一段时间后，服务端自动关闭这个连接。

客户端：
客户端认为这个连接已经建立，如果客户端向服务端发送数据，服务端将以RST包（Reset，标示复位，用于异常的关闭连接）响应。此时，客户端知道第三次握手失败。

八、TCP和UDP

8.1 TCP和UDP的区别？

1. TCP面向连接；UDP是无连接的，即发送数据之前不需要建立连接。
2. TCP提供可靠的服务；UDP不保证可靠交付。
3. TCP面向字节流，把数据看成一连串无结构的字节流；UDP是面向报文的。
4. TCP有拥塞控制；UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应
   用很有用，如实时视频会议等）。
5. 每一条TCP连接只能是点到点的；UDP支持一对一、一对多、多对一和多对多的通信方式。
6. TCP首部开销20字节；UDP的首部开销小，只有8个字节。

8.2 TCP和UDP的使用场景？

• 某些情况下 UDP 确是一种最有效的工作方式（一般用于即时通信），比如： QQ 语音、 QQ 视频 、直播等等。
• TCP 一般用于文件传输、发送和接收邮件、远程登录等场景

九、HTTP协议

9.1 HTTP协议的主要特点有哪些？

1. 支持客户/服务器模式。
2. 简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
3. 灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
4. 无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
5. 无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

9.2 HTTP报文格式是什么？

HTTP请求由请求行、请求头部、空行和请求体四个部分组成。

• 请求行：包括请求方法，访问的资源URL，使用的HTTP版本。 GET 和 POST 是最常见的HTTP方法，除此以外还包括 DELETE、HEAD、OPTIONS、PUT、TRACE 。
• 请求头：格式为“属性名:属性值”，服务端根据请求头获取客户端的信息，主要有 cookie、host、 connection、accept-language、accept-encoding、user-agent 。
• 请求体：用户的请求数据如用户名，密码等。
• 空行：最后一个请求头之后是一个空行，发送回车符和换行符，通知服务器以下不再有请求头。

请求报文示例：

POST /xxx HTTP/1.1 请求行 
Accept:image/gif.image/jpeg, 请求头部 
Accept-Language:zh-cn 
Connection:Keep-Alive 
Host:localhost 
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0) 
Accept-Encoding:gzip,deflate 
username=dabin 请求体

HTTP响应也由四个部分组成，分别是：状态行、响应头、空行和响应体。

• 状态行：协议版本，状态码及状态描述。
• 响应头：响应头字段主要有 connection、content-type、content-encoding、content-length、 set-cookie、Last-Modified、Cache-Control、Expires 。
• 响应体：服务器返回给客户端的内容。

响应报文示例：

HTTP/1.1 200 OK 
Server:Apache Tomcat/5.0.12 
Date:Mon,6Oct2003 13:23:42 GMT 
Content-Length:112 
<html>
	<body>响应体</body>
</html>

9.3 POST和GET的区别？

1. Get 多用于无副作用，幂等的场景；Post 多用于副作用，不幂等的场景；GET一般用于从服务器获取资源，而POST有可能改变服务器上的资源；
2. 缓存：GET请求可被缓存、收藏、保留到历史记录。POST多数情况下不可缓存；
3. 请求形式上：GET请求数据附在URL后面，在HTTP请求头中，而POST在HTTP请求体内；
4. GET只允许ASCII字符，POST对数据类型没有要求，也允许二进制数据；

9.4 HTTP状态码

HTTP状态码表示客户端HTTP请求的返回结果、标记服务器端的处理是否正常或者是出现的错误，能够根据返回的状态码判断请求是否得到正确的处理很重要。

各类别常见状态码：

• 200 OK：客户端请求成功。
• 400 Bad Request：客户端请求有语法错误，不能被服务器所理解。
• 401 Unauthorized：请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用。
• 403 Forbidden：服务器收到请求，但是拒绝提供服务。
• 404 Not Found：请求资源不存在，举个例子：输入了错误的URL。
• 500 Internal Server Error：服务器发生不可预期的错误。
• 503 Server Unavailable：服务器当前不能处理客户端的请求，一段时间后可能恢复正常，举个例子：HTTP/1.1 200 OK（CRLF）。

9.5 什么是长连接和短连接？

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

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

Connection:keep-alive

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

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

9.6 HTTP1.1和 HTTP2.0的区别？

HTTP2.0相比HTTP1.1支持的特性：

• 新的二进制格式：HTTP1.1 基于文本格式传输数据；HTTP2.0采用二进制格式传输数据，解析更高效。
• 多路复用：HTTP2.0在一个连接里，允许同时发送多个请求或响应，并且这些请求或响应能够并行的传输而不被阻塞，避免 HTTP1.1 出现的”队头堵塞”问题。
• 头部压缩：HTTP1.1的header带有大量信息，而且每次都要重复发送；HTTP2.0 把header从数据中分离，并封装成头帧和数据帧，使用特定算法压缩头帧，有效减少头信息大小。并且HTTP2.0在客户端和服务器端记录了之前发送的键值对，对于相同的数据，不会重复发送。比如请求a发送了所有的头信息字段，请求b则只需要发送差异数据，这样可以减少冗余数据，降低开销。
• 服务端推送：HTTP2.0允许服务器向客户端推送资源，无需客户端发送请求到服务器获取。

9.7 HTTPS与HTTP的区别？

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

9.8 HTTP 方法有哪些？

1. GET：获取资源，当前网络中绝大部分使用的都是 GET；
2. HEAD：获取报文首部，和 GET 方法类似，但是不返回报文实体主体部分；
3. POST：传输实体主体
4. PUT：上传文件，由于自身不带验证机制，任何人都可以上传文件，因此存在安全性问题，一般不使用该方法。
5. PATCH：对资源进行部分修改。PUT 也可以用于修改资源，但是只能完全替代原始资源，PATCH 允许部分修改。
6. OPTIONS：查询指定的 URL 支持的方法；
7. CONNECT：要求与代理服务器通信时建立隧道。***L（Secure Sockets Layer，安全套接层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容加密后经网络隧道传输。
8. TRACE：追踪路径。服务器会将通信路径返回给客户端。发送请求时，在 Max-Forwards 首部字段中填入数值，每经过一个服务器就会减 1，当数值为 0 时就停止传输。通常不会使用 TRACE，并且它容易受到 XST 攻击（Cross-Site Tracing，跨站追踪）。
9. Delete：删除文件,与 PUT 功能相反，并且同样不带验证机制。

十、HTTPS原理

首先是TCP三次握手，然后客户端发起一个HTTPS连接建立请求，客户端先发一个 Client Hello的包，然后服务端响应 Server Hello ，接着再给客户端发送它的证书，然后双方经过密钥交换，最后使用交换的密钥加解密数据。

1. 协商加密算法 。在 Client Hello 里面客户端会告知服务端自己当前的一些信息，包括客户端要使用的TLS版本，支持的加密算法，要访问的域名，给服务端生成的一个随机数(Nonce）等。需要提前告知服务器想要访问的域名以便服务器发送相应的域名的证书过来。
2. 服务端响应 Server Hello ，告诉客户端服务端选中的加密算法。
3. 接着服务端给客户端发来了2个证书。第二个证书是第一个证书的签发机构（CA）的证书。
4. 客户端使用证书的认证机构CA公开发布的RSA公钥对该证书进行验证，下图表明证书认证成功。
5. 验证通过之后，浏览器和服务器通过密钥交换算法产生共享的对称密钥。
6. 开始传输数据，使用同一个对称密钥来加解密。

十一、DNS协议

DNS是域名系统（Domain Name System）的简称，因特网上作为域名和IP地址相互映射的一个分布式数据库，能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的IP地址。简单来说，DNS协议则是用来将域名转换为IP地址。

DNS系统：
一个组织的系统管理机构, 维护系统内的每个主机的IP和主机名的对应关系，如果新计算机接入网络，将这个信息注册到数据库中
用户输入域名的时候，会自动查询DNS服务器，由DNS服务器检索数据库，得到对应的IP地址。
我们可以通过命令查看自己的hosts文件：

cat /etc/hosts

域名解析过程：
域名解析总体可分为一下过程：
(1) 输入域名后, 先查找自己主机对应的域名服务器，域名服务器先查找自己的数据库中的数据
(2) 如果没有， 就向上级域名服务器进行查找， 依次类推
(3) 最多回溯到根域名服务器, 肯定能找到这个域名的IP地址
(4) 域名服务器自身也会进行一些缓存， 把曾经访问过的域名和对应的IP地址缓存起来, 可以加速查找过程

具体可描述如下：

1. 浏览器搜索自己的DNS缓存。
2. 若没有，则搜索操作系统中的DNS缓存和hosts文件。
3. 若没有，则操作系统将域名发送至本地域名服务器，本地域名服务器查询自己的DNS缓存，查找成功则返回结果，否则依次向根域名服务器、顶级域名服务器、权限域名服务器发起查询请求，最终返回IP地址给本地域名服务器。
4. 本地域名服务器将得到的IP地址返回给操作系统，同时自己也将IP地址缓存起来。
5. 操作系统将 IP 地址返回给浏览器，同时自己也将IP地址缓存起来。
6. 浏览器得到域名对应的IP地址。

十二、浏览器中输入URL返回页面过程？（重要）

1. 浏览器查询 DNS，获取域名对应的IP地址:具体过程包括浏览器搜索自身的DNS缓存、搜索操作系统的DNS缓存、读取本地的Host文件和向本地DNS服务器进行查询等。对于向本地DNS服务器进行查询，如果要查询的域名包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析(此解析具有权威性)；如果要查询的域名不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析（此解析不具有权威性）。如果本地域名服务器并未缓存该网址映射关系，那么将根据其设置发起递归查询或者迭代查询；
2. 浏览器获得域名对应的IP地址以后，浏览器向服务器请求建立链接，发起三次握手；
3. TCP/IP链接建立起来后，浏览器向服务器发送HTTP请求；
4. 服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理，并将处理结果及相应的视图返回给浏览器；
5. 浏览器解析并渲染视图，若遇到对js文件、css文件及图片等静态资源的引用，则重复上述步骤并向服务器请求这些资源；
6. 浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面。

十三、什么是cookie和session？

由于HTTP协议是无状态的协议，需要用某种机制来识具体的用户身份，用来跟踪用户的整个会话。常用的会话跟踪技术是cookie与session。

cookie就是由服务器发给客户端的特殊信息，而这些信息以文本文件的方式存放在客户端，然后客户端每次向服务器发送请求的时候都会带上这些特殊的信息。说得更具体一些：当用户使用浏览器访问一个支持cookie的网站的时候，用户会提供包括用户名在内的个人信息并且提交至服务器；接着，服务器在向客户端回传相应的超文本的同时也会发回这些个人信息，当然这些信息并不是存放在HTTP响应体中的，而是存放于HTTP响应头；当客户端浏览器接收到来自服务器的响应之后，浏览器会将这些信息存放在一个统一的位置。 自此，客户端再向服务器发送请求的时候，都会把相应的cookie存放在HTTP请求头再次发回至服务器。服务器在接收到来自客户端浏览器的请求之后，就能够通过分析存放于请求头的cookie得到客户端特有的信息，从而动态生成与该客户端相对应的内容。网站的登录界面中“请记住我”这样的选项，就是通过cookie实现的。

cookie工作流程：

1. servlet创建cookie，保存少量数据，发送给浏览器。
2. 浏览器获得服务器发送的cookie数据，将自动的保存到浏览器端。
3. 下次访问时，浏览器将自动携带cookie数据发送给服务器。

session原理：首先浏览器请求服务器访问web站点时，服务器首先会检查这个客户端请求是否已经包含了一个session标识、称为SESSIONID，如果已经包含了一个sessionid则说明以前已经为此客户端创建过session，服务器就按照sessionid把这个session检索出来使用，如果客户端请求不包含session id，则服务器为此客户端创建一个session，并且生成一个与此session相关联的独一无二的sessionid存放到cookie中，这个sessionid将在本次响应中返回到客户端保存，这样在交互的过程中，浏览器端每次请求
时，都会带着这个sessionid，服务器根据这个sessionid就可以找得到对应的session。以此来达到共享数据的目的。 这里需要注意的是，session不会随着浏览器的关闭而死亡，而是等待超时时间。

Cookie和Session的区别？

1. 存储位置不同：Session是服务器端保持状态的方案，Cookie是客户端保持状态的方案
2. 存储容量不同：单个cookie保存的数据<=4KB，一个站点最多保存20个Cookie。对于session来说并没有上限，但出于对服务器端的性能考虑，session内不要存放过多的东西，并且设置session删除机制。
3. 存储方式不同：cookie中只能保管ASCII字符串，并需要通过编码方式存储为Unicode字符或者二进制数据。session中能够存储任何类型的数据，包括且不限于string，integer，list，map等。
4. 隐私策略不同：cookie对客户端是可见的，别有用心的人可以分析存放在本地的cookie并进行cookie欺骗，所以它是不安全的。session存储在服务器上，对客户端透明，不存在敏感信息泄漏的风险。
5. 有效期上不同：开发可以通过设置cookie的属性，达到使cookie长期有效的效果。session依赖于名为JSESSIONID的cookie，而cookie JSESSIONID的过期时间默认为-1，只需关闭窗口该session就会失效，因而session不能达到长期有效的效果。
6. 服务器压力不同：cookie保管在客户端，不占用服务器资源。对于并发用户十分多的网站，cookie是很好的选择。session是保管在服务器端的，每个用户都会产生一个session。假如并发访问的用户十分多，会产生十分多的session，耗费大量的内存。

十四、什么是对称加密和非对称加密？

对称加密：通信双方使用相同的密钥进行加密。特点是加密速度快，但是缺点是密钥泄露会导致密文数据被破解。常见的对称加密有 AES 和 DES 算法。
非对称加密：它需要生成两个密钥，公钥和私钥。公钥是公开的，任何人都可以获得，而私钥是私人保管的。公钥负责加密，私钥负责解密；或者私钥负责加密，公钥负责解密。这种加密算法安全性更高，但是计算量相比对称加密大很多，加密和解密都很慢。常见的非对称算法有 RSA 和 DSA 。

十五、滑动窗口机制

TCP 会将较大数据拆分成一个个小的数据包再进行发送。发送完一个包，等待 ACK，这种模式是最简单的。但是问题也很明显，慢，吞吐量低。所以我们在等待 ACK 的同时，可以继续发送接下来的包。也就是说，滑动窗口就是在发送完一个数据包后，不需要等待 ACK 消息返回，可以发送后面的数据包，解决吞吐量问题。

发送方和接收方各有一个窗口，接收方通过 TCP 报文段中的窗口字段告诉发送方自己的窗口大小，发送方根据这个值和其它信息设置自己的窗口大小。

TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。 TCP会话的双方都各自维护一个发送窗口和一个接收窗口。接收窗口大小取决于应用、系统、硬件的限制。发送窗口则取决于对端通告的接收窗口。接收方发送的确认报文中的window字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将接收方的确认报文window字段设置为 0，则发送方不能发送数据。

TCP头包含window字段，16bit位，它代表的是窗口的字节容量，最大为65535。这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。接收窗口的大小是约等于发送窗口的大小。

十六、拥塞控制

防止过多的数据注入到网络中。 几种拥塞控制方法：慢开始( slow-start )、拥塞避免( congestionavoidance )、快重传( fast retransmit )和快恢复( fast recovery )。

16.1 慢开始

把拥塞窗口 cwnd 设置为一个最大报文段MSS的数值。而在每收到一个对新的报文段的确认后，把拥塞窗口增加至多一个MSS的数值。每经过一个传输轮次，拥塞窗口 cwnd 就加倍。 为了防止拥塞窗口cwnd增长过大引起网络拥塞，还需要设置一个慢开始门限ssthresh状态变量。
当 cwnd < ssthresh 时，使用慢开始算法。
当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。
当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞控制避免算法。

16.2 拥塞避免

让拥塞窗口cwnd缓慢地增大，每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样拥塞窗口cwnd按线性规律缓慢增长。
无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认），就要把慢开始门限ssthresh设置为出现拥塞时的发送 方窗口值的一半（但不能小于2）。然后把拥塞窗口cwnd重新设置为1，执行慢开始算法。这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。

16.3 快重传

有时个别报文段会在网络中丢失，但实际上网络并未发生拥塞。如果发送方迟迟收不到确认，就会产生超时，就会误认为网络发生了拥塞。这就导致发送方错误地启动慢开始，把拥塞窗口cwnd又设置为1，因而降低了传输效率。
快重传算法可以避免这个问题。快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认，使发送方及早知道有报文段没有到达对方。
发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待重传计时器到期。由于发送方尽早重传未被确认的报文段，因此采用快重传后可以使整个网络吞吐量提高约20%。

16.4 快恢复

当发送方连续收到三个重复确认，就会把慢开始门限ssthresh减半，接着把cwnd值设置为慢开始门限ssthresh减半后的数值，然后开始执行拥塞避免算法，使拥塞窗口缓慢地线性增大。
在采用快恢复算法时，慢开始算法只是在TCP连接建立时和网络出现超时时才使用。 采用这样的拥塞控制方法使得TCP的性能有明显的改进。

十七、ARP协议

ARP解决了同一个局域网上的主机和路由器IP和MAC地址的解析。

• 每台主机都会在自己的ARP缓冲区中建立一个ARP列表，以表示IP地址和MAC地址的对应关系。
• 当源主机需要将一个数据包要发送到目的主机时，会首先检查自己 ARP列表中是否存在该 IP地址对应的MAC地址，如果有，就直接将数据包发送到这个MAC地址；如果没有，就向本地网段发起一个ARP请求的广播包，查询此目的主机对应的MAC地址。此ARP请求数据包里包括源主机的IP地址、硬件地址、以及目的主机的IP地址。
• 网络中所有的主机收到这个ARP请求后，会检查数据包中的目的IP是否和自己的IP地址一致。如果不相同就忽略此数据包；如果相同，该主机首先将发送端的MAC地址和IP地址添加到自己的ARP列表中，如果ARP表中已经存在该IP的信息，则将其覆盖，然后给源主机发送一个 ARP响应数据包，告诉对方自己是它需要查找的MAC地址。
• 源主机收到这个ARP响应数据包后，将得到的目的主机的IP地址和MAC地址添加到自己的ARP列表中，并利用此信息开始数据的传输。
• 如果源主机一直没有收到ARP响应数据包，表示ARP查询失败。

十八、Ping的工作原理