关于计算机网络，我与面试官的一场博弈

说一下OSI七层模型和TCP/IP五层模型

TCP五层模型是物理层、数据链路层、网络层、传输层、应用层。七层模型中应用层下会有表示层和会话层，更深入来说一点会话层就是在发送方和接收方之间进行通信时创建、维持、之后终止或断开连接的地方。表示层主要是管理数据传输的表示方式。

get post

• GET - 从指定的资源请求数据。
• POST - 向指定的资源提交要被处理的数据。
• 区别：
  （1）Get 将表单中数据的按照 variable=value 的形式，添加到 action 所指向的 URL 后面，并且两者使用“?”连接，而各个变量之间使用“&”连接；Post 是将表单中的数据放在 form 的数据体中，按照变量和值相对应的方式，传递到 action 所指向 URL。
  （2）Get 是不安全的，因为在传输过程，数据被放在请求的 URL 中，而如今现有的很多服务器、代理服务器或者用户代理都会将请求URL记录到日志文件中，然后放在某个地方，这样就可能会有一些隐私的信息被第三方看到。另外，用户也可以在浏览器上直接看到提交的数据，一些系统内部消息将会一同显示在用户面前。Post 的所有操作对用户来说都是不可见的。
  （3）Get 限制 Form 表单的数据集的值必须为 ASCII 字符；而 Post 支持整个 ISO10646 字符集。使用 Post 传输的数据，可以通过设置编码的方式正确转化中文；而 Get 传输的数据却没有变化。

cookie session 的产生、区别、应用场景

• 产生：http的无状态性

• 区别：
  （1）cookie存在客户端，session在服务端
  （2）机制不同。cookie机制：如果不在浏览器中设置过期时间，cookie被保存在内存中，生命周期随浏览器的关闭而结束，这种cookie简称会话cookie。如果在浏览器中设置了cookie的过期时间，cookie被保存在硬盘中，关闭浏览器后，cookie数据仍然存在，直到过期时间结束才消失。
  session机制：当服务器收到请求需要创建session对象时，首先会检查客户端请求中是否包含sessionid。如果有sessionid，服务器将根据该id返回对应session对象。如果客户端请求中没有sessionid，服务器会创建新的session对象，并把sessionid在本次响应中返回给客户端。通常使用cookie方式存储sessionid到客户端，在交互中浏览器按照规则将sessionid发送给服务器。
  （3）储存内容。cookie只能存字符串类型，session通过类似与Hashtable的数据结构来保存，能支持任何类型的对象
  （4）大小，cookie不能超4k，session没限制
  （5）安全 sessionID加密，相对安全

• 应用场景：

• cookie：
  （1）判断用户是否登陆过网站，以便下次登录时能够实现自动登录（或者记住密码）。如果我们删除cookie，则每次登录必须从新填写登录的相关信息。
  （2）保存上次登录的时间等信息。
  （3）保存上次查看的页面
  （4）浏览计数

• session
  Session用于保存每个用户的专用信息，变量的值保存在服务器端，通过SessionID来区分不同的客户。
  （1）网上商城中的购物车
  （2）保存用户登录信息
  （3）将某些数据放入session中，供同一用户的不同页面使用
  （4）防止用户非法登录

说一下TCP与UDP

他们都是传输层的协议。TCP是面向字节流的，UDP是面向数据报的：因为UDP只是把应用层交下来的报文加上首部后就向下层传输，应用层交给UDP多长的报文，UDP就照样发送。而TCP是把应用层交下来的数据看成无结构的字节流来发送，发送方TCP会将数据放入（缓存区），等到可以发送的时候就发送，不能发送就先暂时等待，TCP会根据当前网络的拥塞状态来确定每个报文段的大小。
TCP在传输之前需要建立连接，它是可靠传输，UDP知道对端的IP和端口号就直接进行传输，不需要建立连接，UDP使用尽最大努力交付，不保证可靠交付，不需要维持复杂的连接状态。
对于套接字TCP是一对一连接，UDP支持多对多连接。
常见使用TCP的服务：FTP，SMTP，HTTP，Telnet
常见使用UDP的服务：DNS，SNMP（它们数据包总量比较少）

你刚才说TCP是可靠传输的，详细说下它是如何保证可靠的？

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

详细说一下TCP的滑动窗口和拥塞控制？

滑动窗口：窗口的大小是在TCP三次握手后协定的，并且窗口的大小并不是固定的，而是会随着网络的情况进行调整。对于发送端来说，要发送的报文段排成队列，会有一个滑动窗口覆盖要发送的报文段，当接收端确认某个报文段后且这个窗口中这个报文段之前的也都被收到，他们便都从窗口划出。用窗口进行流量控制，也保证了传输的可靠。

拥塞控制：对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏，这种情就叫做网络拥塞。如果出现拥塞不进行控制，整个网络吞吐量大幅下降。
TCP的四种拥塞控制算法：
1.慢开始
2.拥塞避免
3.快重传
4.快恢复

发送方维护一个cwnd拥塞窗口的值，发送方每收到一个对新报文段的确认时，就把拥塞窗口cwnd的值增加，然后开始下一轮的传输。在达到慢开始门限值之前，cwnd基本上是程指数级增加，达到门限值之后会做调整：cwnd变为线性增加，这个状态称为拥塞避免状态。
在拥塞避免状态发生超时重传，判断网络可能出现拥塞，此时1）将新门限值设为一半 2）cwnd设为1，重新开始慢开始算法。
快重传：接收方需要发送方立即发送确认，发送方一旦收到3个重复确认ACK，就启动快重传算法，降低门限，进入拥塞避免阶段。这样可以整体提高网络吞吐量。

快速重传算法可以概括如下：TCP发送端在观测到至少dupthresh个重复ACK后，即重传可能丢失的数据分组，而不必等到重传计时器超时

说一下从输入一个网页到最终获取页面信息这整个过程吧

• 浏览器查找该域名的 IP 地址
  首先看是否击中浏览器相应的URL-IP缓存，接下来找系统、路由器里有没有相应缓存，如果没有需要DNS寻址，由主机向本地服务器进行递归查询，本地服务器向根域名服务器，顶级域名服务器、权威域名服务器进行迭代查询。
• 根据解析到的IP，三次握手建立TCP连接
• 建立连接成功，客户端向服务端发送HTTP请求
• 服务器响应HTTP请求
• 浏览器解析HTML代码并请求html中的静态资源
• 关闭TCP连接（四次挥手）
• 浏览器渲染页面

附加：用到了那些协议？

解析IP：DNS（应用层） UDP（传输层）
传输报文 HTTP HTTPS 应用层
握手连接：TCP 传输层
IP广播 mac寻址： ARP 网络层

详细说一下三次握手和四次挥手过程

第一次握手：客户端发送syn包(syn=1，seq=x)到服务器，并进入SYN_SENT状态，等待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=y+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。

第一次挥手：主动关闭方发送一个FIN，用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：我已经不 会再给你发数据了(当然，在fin包之前发送出去的数据，如果没有收到对应的ack确认报文，主动关闭方依然会重发这些数据)，但是，此时主动关闭方还可以接受数据。
第二次挥手：被动关闭方收到FIN包后，发送一个ACK给对方，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号）。
第三次挥手：被动关闭方发送一个FIN，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会再给你发数据了。
第四次挥手：主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手。

• 为什么是三次握手，不是二次，四次？

三次握手可以保证：
1）避免历史连接，浪费资源。最主要的原因是防止历史连接初始化了连接。如果两次握手即可建立连接，则历史第二次握手的丢失信号即可再次建立连接。如果是三次握手，客户端可对此进行判断，并发送RST标志位报文段给服务端，表示终止连接。
2） 同步双方序列号，保证初始序列号都能被对方确认接收。

• 为什么是四次挥手？

关闭连接时，客户端向服务端发送 FIN 时，仅仅表示客户端不再发送数据了但是还能接收数据。服务器收到客户端的 FIN 报文时，先回一个 ACK 应答报文，而服务端可能还有数据需要处理和发送，等服务端不再发送数据时，才发送 FIN 报文给客户端来表示同意现在关闭连接。

• 服务端的Time_Wait状态再哪个阶段出现？持续多久？为什么要设计这么一个状态？

timewait阶段是最后阶段发送确认收到server端的fin报文释放连接请求后回复给server端ack报文，之后client端就进入time_wait阶段。
设立这个状态主要是保证client端确认server端收到最后的FIN报文，等一个计时器时间2MSL，如果该时间段内再次收到server的fin报文 那client就必须回复。如果没有收到，client就认为server端已经接收到了最后的ack报文。

HTTP和HTTPS的区别

建立SSL连接 - 服务端传回证书、公钥信息 - 客户端使用公钥加密私钥信息 - 通过私钥信息加密对话

用公钥和私钥加密/解密对称秘钥，用对称秘钥加密传输信息****用非对称加密来传输对称密钥来保证安全性，使用对称加密来保证通信的效率。

HTTPS的加密过程：
客户端向服务端发起第一次握手请求，告诉服务端客户端所支持的SSL的指定版本、加密算法及密钥长度等信息。
服务端将自己的公钥发给数字证书认证机构，数字证书认证机构利用自己的私钥对服务器的公钥进行数字签名，并给服务器颁发公钥证书。
服务端将证书发给客服端。
客服端利用数字认证机构的公钥，向数字证书认证机构验证公钥证书上的数字签名，确认服务器公开密钥的真实性。
客服端使用服务端的公开密钥加密自己生成的对称密钥，发给服务端。
服务端收到后利用私钥解密信息，获得客户端发来的对称密钥。
通信双方可用对称密钥来加密解密信息。
上述流程存在的一个问题是客户端哪里来的数字认证机构的公钥，其实，在很多浏览器开发时，会内置常用数字证书认证机构的公钥。

SSH：
对称秘钥保证数据机密
基于证书利用数字签名方法对服务端、客户验证鉴权。
MAC算法保证消息完整性

TCP头部字段

常用加密算法

• 不可逆加密：
  MD5，HMAC，SHA1（安全散列），加密过程不可逆，因此比较常用的场景就是用户密码加密，其验证过程就是通过比较两个加密后的字符串是否一样来确认身份

• 对称加密
  在数据加密和解密的时用的都是同一个密钥：DES、3DES、AES128

• 非对称加密 RSA SM2