OSI七层网络模型，五层网络模型，TCP/IP四层模型？
详见 https://snailclimb.gitee.io/javaguide-interview/#/./docs/c-1%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C
应用层(application-layer）：通过应用进程间的交互来完成特定网络应用。应用层协议定义的是应用进程间的通信和交互的规则。对于不同的网络应用需要不同的应用层协议，如域名系统DNS，支持万维网应用的 HTTP协议，支持电子邮件的 SMTP协议等。
表示层：处理所有与数据表示及运输有关的问题，包括转换、加密和压缩。
会话层：不同机器之间建立及管理会话。
运输层(transport layer)：负责向两台主机进程之间的通信提供通用的数据传输服务。应用进程利用该服务传送应用层报文。“通用的”是指并不针对某一个特定的网络应用，而是多种应用可以使用同一个运输层服务。运输层主要使用TCP和UDP两种协议。
网络层：在计算机网络中进行通信的两个计算机之间可能会经过很多个数据链路，也可能还要经过很多通信子网。网络层的任务就是选择合适的网间路由和交换结点， 确保数据及时传送。 在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送。涉及的协议有IP，ICMP，RIP，IGMP等。
数据链路层(data link layer)：两台主机之间的数据传输，总是在一段一段的链路上传送的，这就需要使用专门的链路层的协议。 在两个相邻节点之间传送数据时，数据链路层将网络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。每一帧包括数据和必要的控制信息（如同步信息，地址信息，差错控制等）。
物理层(physical layer)：实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异。
五层就是上三层合并成应用层，四层就是下两层是网络接口层，网络层是网际层-
常见应用层协议和运输层、网络层协议，以及硬件如路由器之类在哪一层？
常见协议
数据在各层之间的传递过程？
在向下的过程中，需要添加下层协议所需要的首部或者尾部，而在向上的过程中不断拆开首部和尾部。路由器只有下面三层协议，因为路由器位于网络核心中，不需要为进程或者应用程序提供服务，因此也就不需要传输层和应用层。-
三次握手的过程？为什么三次？
第一次，客户端发送SYN报文，SYN标志位置为 1，表示请求建立连接，随机初始序列号x,之后客户端处于 SYN-SENT 状态．第二次，服务端收到SYN报文，置SYN=1,ACK=1．随机生成序列号y，同时将确认号x+1填入到tcp报文的首部,把报文发送给客户端，之后服务端处于 SYN-RCVD 状态。第三次，客户端收到了服务端的报文，再返回ACK报文，其序列号x+1，确认号y+1，这次报文可以携带数据．之后客户端处于 ESTABLISHED 状态。服务器收到客户端的应答报文后，也进入 ESTABLISHED 状态。连接建立完成．
三次的主要原因是TCP 建立连接时，首要原因是为了防止旧的重复连接初始化造成混乱，能减少双方不必要的资源开销，能帮助双方同步初始化序列号。序列号能够保证数据包不重复、不丢弃和按序传输。如果客户端发送多个建立连接的SYN报文，在网络拥堵等情况下，旧的报文可能先到达，如果是两次握手连接，就不能判断当前连接是否是历史连接，三次握手则可以在客户端准备发送第三次报文时，客户端因有足够的上下文来判断当前连接是否是历史连接：如果是历史连接（序列号过期或超时），则第三次握手发送的报文是 RST 报文，以此中止历史连接；如果不是历史连接，则第三次发送的报文是 ACK 报文，通信双方就会成功建立连接。当客户端发送携带初始序列号的 SYN 报文的时候，需要服务端回一个 ACK 应答报文，表示客户端的 SYN 报文已被服务端成功接收，那当服务端发送初始序列号给客户端的时候，依然也要得到客户端的应答回应，这样一来一回，才能确保双方的初始序列号能被可靠的同步。(两次握手：无法防止历史连接的建立，会造成双方资源的浪费，也无法可靠的同步双方序列号；四次握手：三次握手就已经理论上最少可靠连接建立，所以不需要使用更多的通信次数。)
三次握手 -
四次挥手的过程？为啥四次？三次行不？
第一次，发起断开的一方发送FIN报文，请求断开连接，进入FIN_WAIT_1状态。第二次，接受方收到该报文后，就向发起方发送 ACK 应答报文，接着进入 CLOSED_WAIT 状态，发起方收到ACK报文，进入到FIN_WAIT_2状态。第三次，处理完数据后，接受方也向发起方发送 FIN 报文，之后进入 LAST_ACK 状态。第四次，发起方收到FIN报文，回一个 ACK 应答报文，之后进入 TIME_WAIT 状态。接收方收到了 ACK 应答报文后，就进入了 CLOSE 状态，至此接收方已经完成连接的关闭。发起方在经过 2MSL 一段时间后，自动进入 CLOSE 状态，至此发起方也完成连接的关闭。接收端通常需要等待完成数据的发送和处理，所以 ACK 和 FIN 一般都会分开发送，从而比三次握手导致多了一次。如果不需要处理和传输数据，理论上三次也可以。
四次挥手.png 为什么需要 TIME_WAIT 状态？为什么 TIME_WAIT 等待的时间是 2MSL？
主动发起关闭连接的一方，才会有 TIME-WAIT 状态。需要 TIME-WAIT 状态，主要是两个原因：
１．防止具有相同四元组的旧数据包被收到,影响下一次连接．由于TIME_WAIT状态持续时间为2MSL，这样保证了旧TCP连接双工链路中的旧数据包均因过期而消失，此后，就可以用相同的四元组建立一条新连接而不会发生前后两次连接数据错乱的情况；
２．保证被动关闭连接的一方能被正确的关闭，即保证最后的 ACK 能让被动关闭方接收，从而使其正常关闭；
MSL是“报文最大生存时间”，他是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。主动方发送的ACK报文段，在网络中存活 1 MSL，因此被动方只要在1MSL时间单位内没接收到主动方的ACK报文段，就会重传．被动方重传的 FIN 报文段，在网络中最长存活时间也是 1MSL．因此，只有主动方等待2个单位的MSL，才能确保可以收到被动方的重传FIN报文．2MSL 的时间是从客户端接收到 FIN 后发送 ACK 开始计时的。如果在 TIME-WAIT 时间内，因为客户端的 ACK 没有传输到服务端，客户端又接收到了服务端重发的 FIN 报文，那么 2MSL 时间将重新计时。这2个MSL中的第一个MSL是为了等自己发出去的最后一个ACK从网络中消失，而第二MSL是为了等在对端收到ACK之前的一刹那可能重传的FIN报文从网络中消失。另外，虽然说维持TIME_WAIT状态一段时间有2个目的，但这段时间具体应该多长主要是为了达成上述第一个目的而设计的。
查看: netstat -a | grep TIME_WAIT | wc -l为什么会TIME-WAIT过多？危害？解决方法是怎样的？
原因：
TIME-WAIT过多的本质原因是大量短连接的存在。
危害：
第一是内存资源占用；
第二是对端口资源的占用，一个 TCP 连接至少消耗一个端口，端口是有限的
解决方法：
客户端：HTTP 请求的头部，connection 设置为 keep-alive，保持存活一段时间
服务器端：修改内核参数。允许TIME-WAIT 状态的 socket 被重用；缩减 TIME-WAIT时间；修改TIME-WAIT状态连接的上限值。-
TCP与UDP区别和应用场景，基于TCP的协议有哪些，基于UDP的有哪些？
协议：
常见协议.png
DNS 可以使用 UDP 或者 TCP 进行传输，使用的端口号都为 53。大多数情况下 DNS 使用 UDP 进行传输，这就要求域名解析器和域名服务器都必须自己处理超时和重传从而保证可靠性。在两种情况下会使用 TCP 进行传输：如果返回的响应超过的 512 字节（UDP 最大只支持 512 字节的数据）。区域传送（区域传送是主域名服务器向辅助域名服务器传送变化的那部分数据）。
TCP与UDP区别：
1、TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接
2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付
3、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的。UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）
4、每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信
5、TCP首部开销20字节;UDP的首部开销小，只有8个字节
6、TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道
UDP 的主要应用场景
需要资源少，对于丢包不敏感的应用，不需要一对一沟通，而是可以广播的应用。因为它不面向连接，所以可以做到一对多，承担广播或者多播的协议。需要处理速度快，可以容忍丢包，但是即使网络拥塞，也毫不退缩，一往无前的时候。
基于 UDP 的几个例子
直播。直播对实时性的要求比较高，宁可丢包，也不要卡顿的，所以很多直播应用都基于 UDP 实现了自己的视频传输协议
实时游戏。游戏的特点也是实时性比较高，在这种情况下，采用自定义的可靠的 UDP 协议，自定义重传策略，能够把产生的延迟降到最低，减少网络问题对游戏造成的影响
物联网。一方面，物联网领域中断资源少，很可能只是个很小的嵌入式系统，而维护 TCP 协议的代价太大了；另一方面，物联网对实时性的要求也特别高。
许多应用只支持UDP，如：多媒体数据流，不产生任何额外的数据，即使知道有破坏的包也不进行重发。
视频聊天
TCP 的主要应用场景
适用于对数据传输可靠性要求比较高的场景，例如文本传输。
互联网和企业网上客户端应用，数据传输性能让位于数据传输的完整性，可控制性和可靠性。发消息的场景以及文件传输，要确保发送的消息不丢失
TCP可靠传输的保证，拥塞控制目的和过程？
详见：https://www.cnblogs.com/xiaokang01/p/10033267.html
①校验和：校验数据包是否出错，https://www.cnblogs.com/iamwho/p/11510160.html
②序列号：用来解决网络包乱序问题。接收方可以去除重复的数据；接收方可以根据数据包的序列号按序接收。
③确认应答：解决丢包的问题，可以标识发送出去的数据包中， 哪些是已经被对方收到的；(接收方收到报文就会确认，累积确认：对所有按序接收的数据的确认)
④超时重传：当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。
⑤连接管理：三次握手和四次挥手
⑥流量控制：让接收方能来得及接收数据
⑦拥塞控制：降低整个网络的拥塞程度。
拥塞控制目的：拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。相反，流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制是为了让接收方能来得及接收，而拥塞控制是为了降低整个网络的拥塞程度。
拥塞控制过程：
慢开始与拥塞避免：发送的最初执行慢开始，令 cwnd = 1，发送方只能发送 1 个报文段；当收到确认后，将 cwnd 加倍，因此之后发送方能够发送的报文段数量为：2、4、8 ...慢开始每个轮次都将 cwnd 加倍，这样会让 cwnd 增长速度非常快，从而使得发送方发送的速度增长速度过快，网络拥塞的可能性也就更高。设置一个慢开始门限 ssthresh，当 cwnd >= ssthresh 时，进入拥塞避免，每个轮次只将 cwnd 加 1。如果出现了超时，则令 ssthresh = cwnd / 2，然后重新执行慢开始。
快重传与快恢复：当连续收到三个重复的确认报文时，触发快速恢复。在这种情况下，只是丢失个别报文段，而不是网络拥塞。因此执行快恢复，令 ssthresh = cwnd / 2 ，cwnd = ssthresh，此时直接进入拥塞避免。
http://www.cyc2018.xyz/%E8%AE%A1%E7%AE%97%E6%9C%BA%E5%9F%BA%E7%A1%80/%E7%BD%91%E7%BB%9C%E5%9F%BA%E7%A1%80/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C%20-%20%E4%BC%A0%E8%BE%93%E5%B1%82.html#tcp-%E6%8B%A5%E5%A1%9E%E6%8E%A7%E5%88%B6TCP粘包现象原因和解决方法
详见：JavaInterview第36页的TCP粘包部分：
TCP 协议是面向字节流的协议，没有消息和数据包等概念，它可能会组合或者拆分应用层协议的数据；应用层协议的没有定义消息的边界导致数据的接收方无法拼接数据；
方法①在报文末尾增加换行符表明一条完整的消息，这样在接收端可以根据这个换行符来判断消息是否完整。
方法②将消息分为消息头、消息体。可以在消息头中声明消息的长度，根据这个长度来获取报文（比如 808 协议）。
方法③规定好报文长度，不足的空位补齐，取的时候按照长度截取即可浏览器输入一条URL后发生了什么？相关协议
①首先对 URL 进行解析，浏览器确定 Web 服务器和文件名，根据这些信息来生成 HTTP 请求消息．
②生成 HTTP 消息后，需要委托操作系统将消息发送给 Web 服务器，在发送前需要使用DNS协议查询web服务器的域名相对应的ip地址，因为委托操作系统发送消息时，必须提供通信对象的 IP 地址．首先会先查找浏览器上面的缓存，再查找.host文件的缓存。如果没有会发送一个DNS请求给本地DNS域名服务器。本地域名服务器收到客户端的请求后，如果缓存里的表格能找到。则它直接返回 IP 地址。如果没有，本地 DNS 会去问它的根域名服务器．根 DNS 收到来自本地 DNS 的请求后，告诉本地域名服务器该域名的顶级域名服务器地址。本地DNS再去问顶级域名服务器，顶级域名服务器地址告诉本地DNS 权威DNS服务器地址，本地DNS再去问 这就拿到了ip地址了．
③拿到ip地址后，通过TCP协议传输HTTP请求，在 HTTP 传输数据之前，首先需要通过三次握手建立TCP连接(简单说一下过程)。在双方建立了连接后，TCP 报文中的数据部分就是HTTP 头部 + 数据，组装好 TCP 报文之后，交给下面的网络层处理。
④IP层为TCP报文添加IP头部信息，包括源地址IP，目的地址IP等．
⑤网卡驱动从 IP 模块获取到包之后，会将其复制到网卡内的缓存区中，接着会在其开头加上MAC头和起始帧分界符，在末尾加上用于检测错误的帧校验序列。然后将数字信息转换为电信号，在网线上传输，经过交换机和路由器最终到达服务器．
⑥服务器层层解析，将浏览器请求的数据返回。最后浏览器获得数据后进行渲染就能呈现出页面出来了．-
HTTP1.0、1.1、2.0之间的区别
详见 JavaInertview第五页的“HTTP1.0、1.1、2.0之间的区别”
HTTP版本区别.png HTTP 常见的状态码，有哪些？
1xx 类状态码属于提示信息，是协议处理中的一种中间状态
2xx 类状态码表示服务器成功处理了客户端的请求「200 OK」是最常见的成功状态码，表示一切正常。如果是非 HEAD 请求，服务器返回的响应头都会有 body 数据。「204 No Content」也是常见的成功状态码，与 200 OK 基本相同，但响应头没有 body 数据。「206 Partial Content」是应用于 HTTP 分块下载或断电续传，表示响应返回的 body 数据并不是资源的全部，而是其中的一部分，也是服务器处理成功的状态。
3xx 类状态码表示客户端请求的资源发送了变动，需要客户端用新的 URL 重新发送请求获取资源，也就是重定向。「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问。「302 Moved Temporarily」表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问。301 和 302 都会在响应头里使用字段 Location，指明后续要跳转的 URL，浏览器会自动重定向新的 URL。「304 Not Modified」不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，用于缓存控制(客户端第一次对服务器发出GET请求，客户端浏览器缓存了该页面，当客户端第二次对服务器发出同样的GET请求时，若客户端缓存中的If-Modified-Since过期，客户端将向服务器发出GET请求，验证If-Modified-Since和If-None-Match是否与web server中信息一致，如果Get页面未做任何修改，服务器就是对客户端返回304 Not Modified，客户端直接从本地缓存中将页面资源调取)。
4xx 类状态码表示客户端发送的报文有误，服务器无法处理，也就是错误码的含义。「400 Bad Request」表示客户端请求的报文有错误，但只是个笼统的错误。「403 Forbidden」表示服务器禁止访问资源，并不是客户端的请求出错。「404 Not Found」表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端。
5xx 类状态码表示客户端请求报文正确，但是服务器处理时内部发生了错误，属于服务器端的错误码。「500 Internal Server Error」与 400 类型，是个笼统通用的错误码，服务器发生了什么错误，我们并不知道。「501 Not Implemented」表示客户端请求的功能还不支持，类似“即将开业，敬请期待”的意思。「502 Bad Gateway」通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。「503 Service Unavailable」表示服务器当前很忙，暂时无法响应服务器，类似“网络服务正忙，请稍后重试”的意思。HTTP1.0、1.1、2.0以及3.0之间的区别？
HTTP１.0
优点：简单，灵活易于扩展，应用广泛和跨平台．
双刃剑：无状态和明文传输
缺点：不安全（明文通信，窃取风险，不验证完整性，篡改风险，不验证通信放身份，冒充风险）
HTTP1.1优点：新增了长连接(减少了 TCP 连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。)和管道传输(即可在同一个 TCP 连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间).
缺点：
队头阻塞，即当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一同被阻塞了，会招致客户端一直请求不到数据．
请求 / 响应头部（Header）未经压缩就发送，首部信息越多延迟越大。只能压缩 Body 的部分；
发送冗长的首部。每次互相发送相同的首部造成的浪费较多；
没有请求优先级控制；
请求只能从客户端开始，服务器只能被动响应。
HTTP/2
相比 HTTP/1.1 性能上的改进：
使用HPACK压缩头部：HTTP/2 会压缩头（Header）如果同时发出多个请求，他们的头是一样的或是相似的，那么，协议会消除重复的部分。这就是所谓的 HPACK 算法：在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。
二进制格式：HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了二进制格式。头信息和数据体都是二进制，并且统称为帧（frame）：头信息帧和数据帧。因为计算机只懂二进制，那么收到报文后，无需再将明文的报文转成二进制，而是直接解析二进制报文，这增加了数据传输的效率。
数据流：HTTP/2 的数据包不是按顺序发送的，同一个连接里面连续的数据包，可能属于不同的回应。因此，必须要对数据包做标记，指出它属于哪个回应。每个请求或回应的所有数据包，称为一个数据流（Stream）。每个数据流都标记着一个独一无二的编号，其中规定客户端发出的数据流编号为奇数， 服务器发出的数据流编号为偶数．客户端还可以指定数据流的优先级。优先级高的请求，服务器就先响应该请求。
多路复用：HTTP/2 是可以在一个连接中并发多个请求或回应，而不用按照顺序一一对应。移除了 HTTP/1.1 中的串行请求，不需要排队等待，也就不会再出现「队头阻塞」问题，降低了延迟，大幅度提高了连接的利用率。
服务器推送：HTTP/2 还在一定程度上改善了传统的「请求 - 应答」工作模式，服务不再是被动地响应，也可以主动向客户端发送消息。举例来说，在浏览器刚请求 HTML 的时候，就提前把可能会用到的 JS、CSS 文件等静态资源主动发给客户端，减少延时的等待，也就是服务器推送（Server Push，也叫 Cache Push）。
缺点：HTTP/2 主要的问题在于：多个 HTTP 请求在复用一个 TCP 连接，下层的 TCP 协议是不知道有多少个 HTTP 请求的。所以一旦发生了丢包现象，就会触发 TCP 的重传机制，这样在一个 TCP 连接中的所有的 HTTP 请求都必须等待这个丢了的包被重传回来。
HTTP3：
HTTP/1.1 中的管道（ pipeline）传输中如果有一个请求阻塞了，那么队列后请求也统统被阻塞住了
HTTP/2 多请求复用一个TCP连接，一旦发生丢包，就会阻塞住所有的 HTTP 请求。
这都是基于 TCP 传输层的问题，所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP！UDP 是不可靠传输的，但基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输：
QUIC 有自己的一套机制可以保证传输的可靠性的。当某个流发生丢包时，只会阻塞这个流，其他流不会受到影响。
TL3 升级成了最新的 1.3 版本，头部压缩算法也升级成了 QPack。
HTTPS 要建立一个连接，要花费 6 次交互，先是建立三次握手，然后是 TLS/1.3 的三次握手。QUIC 直接把以往的 TCP 和 TLS/1.3 的 6 次交互合并成了 3 次，减少了交互次数。HTTP与HTTPS之间的区别，了解对称加密和非对称加密算法不？
①HTTPS协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
②HTTP是超文本传输协议，信息是明文传输，HTTPS则是具有安全性的ssl/tsl加密传输协议。
③HTTP和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
④HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。
对称加密：密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密算法有DES、AES等；
非对称加密：密钥成对出现（且根据公钥无法推知私钥，根据私钥也无法推知公钥），加密解密使用不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢，典型的非对称加密算法有RSA、DSA等。HTTP请求有哪些，多说点。Post和get区别。
详见http://www.cyc2018.xyz/%E8%AE%A1%E7%AE%97%E6%9C%BA%E5%9F%BA%E7%A1%80/HTTP/HTTP.html#%E4%BA%8C%E3%80%81http-%E6%96%B9%E6%B3%95
GET：获取资源
HEAD：获取报文头部，不返回报文实体主体部分。主要用于确认 URL 的有效性以及资源更新的日期时间等。
POST：传输数据
PUT：上传文件，无验证机制，因此存在安全性问题，一般不用
DELETE：删除文件，与 PUT 功能相反，并且同样不带验证机制
PATCH：对资源进行部分修改
OPTIONS：查询指定的 URL 能够支持的方法。
CONNECT：使用 SSL（Secure Sockets Layer）和 TLS（Transport Layer Security）协议把通信内容加密后经网络隧道传输。
TRACE：服务器会将通信路径返回给客户端。它容易受到 XST 攻击
GET用于信息获取，而且应该是安全的和幂等的。
POST表示可能修改变服务器上的资源的请求，不是安全和幂等的。
HTTP 并未规定不可以 GET 中发送 Body 内容，但却不少知名的工具不能用 GET 发送 Body 数据，所以大致的讲我们仍然不推荐使用 GET 携带 Body 内容，还有可能某些应用服务器也会忽略掉 GET 的 Body数据重定向和转发区别
①.转发在服务器端完成的;重定向是在客户端完成的
②.转发的速度快;重定向速度慢
③.转发的是同一次请求，地址栏无变化;重定向是两次不同请求，地址栏有变化
④.转发不会执行转发后的代码;重定向会执行重定向之后的代码
⑥.转发必须是在同一台服务器下完成;重定向可以在不同的服务器下完成cookie和session区别。
详见 https://juejin.cn/post/6844904034181070861
cookie和session都是用来跟踪浏览器用户身份的会话方式。主要区别是：cookie数据保存在客户端，session数据保存在服务器端。Session的实现依赖于Cookies，经常会把Session ID 存放在Cookie中。具体区别如下：
①安全性： Session 比 Cookie 安全，Session 是存储在服务器端的，Cookie 是存储在客户端的。
②存取值的类型不同：Cookie 只支持存字符串数据，想要设置其他类型的数据，需要将其转换成字符串，Session 可以存任意数据类型。
③有效期不同： Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭（默认情况下）或者 Session 超时都会失效。
④存储大小不同： 单个 Cookie 保存的数据不能超过 4K，Session 可存储数据远高于 Cookie，但是当访问量过多，会占用过多的服务器资源。
18.Ping命令的工作原理
ping 是基于 ICMP 协议工作的，也就是互联网控制报文协议．ICMP 主要的功能包括：确认 IP 包是否成功送达目标地址、报告发送过程中 IP 包被废弃的原因和改善网络设置等。ICMP 报文封装在 IP 包里面，它工作在网络层，是 IP 协议的助手。ICMP 的类型，大致可以分为两大类：一类是用于诊断的查询消息，也就是「查询报文类型」另一类是通知出错原因的错误消息，也就是「差错报文类型．Ping 命令就是利用查询报文类型中的回送消息实现的(回送请求(8)，回送应答(0))。
充分利用 ICMP 差错报文类型的应用叫做 traceroute：traceroute 的第一个作用就是故意设置特殊的 TTL，来追踪去往目的地时沿途经过的路由器．traceroute 还有一个作用是故意设置不分片，从而确定路径的 MTU。
19.Http常见字段？
①Host： 客户端发送请求时，指定服务器的域名，如Host: www.A.com
②Centent-Length：服务器返回消息时，表明本次数传的数据长度，如Content-Length: 1000
③Connection：表示客户端要求建立可以复用的持久连接(长连接)．如Connection: keep-alive
④Content-Type：表示服务器返回数据的格式，如Content-Type: text/html; charset=utf-8
⑤Accept：客户端发送消息时表示自己能接收的数据格式，如Accept:/
⑥Context-Encoding：表示服务器返回数据的压缩格式，如Context-Encoding:gzip
⑦Accept-Encoding：表示客户端可以接收的压缩格式，如Accept-Encoding:gzip,deflate
20.HTTPS建立连接的过程？
SSL/TLS 协议基本流程：
客户端向服务器索要并验证服务器的公钥。
双方协商生产「会话秘钥」。
双方采用「会话秘钥」进行加密通信
前两步也就是 SSL/TLS 的建立过程，也就是握手阶段。SSL/TLS 的「握手阶段」涉及四次通信：
1.ClientHello
首先，由客户端向服务器发起加密通信请求，也就是 ClientHello 请求。
在这一步，客户端主要向服务器发送以下信息：
（1）客户端支持的 SSL/TLS 协议版本，如 TLS 1.2 版本。
（2）客户端生产的随机数（Client Random），后面用于生产「会话秘钥」。
（3）客户端支持的密码套件列表，如 RSA 加密算法。
2.SeverHello
服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello。服务器回应的内容有如下内容：
（1）确认 SSL/ TLS 协议版本，如果浏览器不支持，则关闭加密通信。
（2）服务器生产的随机数（Server Random），后面用于生产「会话秘钥」。
（3）确认的密码套件列表，如 RSA 加密算法。
（4）服务器的数字证书。
3.客户端回应
客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。
如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：
（1）一个随机数（pre-master key）。该随机数会被服务器公钥加密。
（2）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。
（3）客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供服务端校验。
上面第一项的随机数是整个握手阶段的第三个随机数，这样服务器和客户端就同时有三个随机数，接着就用双方协商的加密算法，各自生成本次通信的「会话秘钥」。
4.服务器的最后回应
服务器收到客户端的第三个随机数（pre-master key）之后，通过协商的加密算法，计算出本次通信的「会话秘钥」。然后，向客户端发生最后的信息：
（1）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。
（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验。
至此，整个 SSL/TLS 的握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的 HTTP 协议，只不过用「会话秘钥」加密内容。
21.优化HTTPS的手段？
对于硬件优化的方向，因为 HTTPS 是属于计算密集型，应该选择计算力更强的 CPU，而且最好选择支持 AES-NI 特性的 CPU，这个特性可以在硬件级别优化 AES 对称加密算法，加快应用数据的加解密。
对于软件优化的方向，如果可以，把软件升级成较新的版本，比如将 Linux 内核 2.X 升级成 4.X，将 openssl 1.0.1 升级到 1.1.1，因为新版本的软件不仅会提供新的特性，而且还会修复老版本的问题。
对于协议优化的方向：
密钥交换算法应该选择 ECDHE 算法，而不用 RSA 算法，因为 ECDHE 算法具备前向安全性，而且客户端可以在第三次握手之后，就发送加密应用数据，节省了 1 RTT。
将 TSL1.2 升级 TSL1.3，因为 TSL1.3 的握手过程只需要 1 RTT，而且安全性更强。
对于证书优化的方向：
服务器应该选用 ECDSA 证书，而非 RSA 证书，因为在相同安全级别下，ECC 的密钥长度比 RSA 短很多，这样可以提高证书传输的效率；
服务器应该开启 OCSP Stapling 功能，由服务器预先获得 OCSP 的响应，并把响应结果缓存起来，这样 TLS 握手的时候就不用再访问 CA 服务器，减少了网络通信的开销，提高了证书验证的效率；
对于重连 HTTPS 时，我们可以使用一些技术让客户端和服务端使用上一次 HTTPS 连接使用的会话密钥，直接恢复会话，而不用再重新走完整的 TLS 握手过程。
常见的会话重用技术有 Session ID 和 Session Ticket，用了会话重用技术，当再次重连 HTTPS 时，只需要 1 RTT 就可以恢复会话。对于 TLS1.3 使用 Pre-shared Key 会话重用技术，只需要 0 RTT 就可以恢复会话。
这些会话重用技术虽然好用，但是存在一定的安全风险，它们不仅不具备前向安全，而且有重放攻击的风险，所以应当对会话密钥设定一个合理的过期时间
22.什么是 SYN 攻击？如何避免 SYN 攻击？
SYN攻击：假设攻击者短时间伪造不同 IP 地址的 SYN 报文，服务端每接收到一个 SYN 报文，就进入SYN_RCVD 状态，但服务端发送出去的 ACK + SYN 报文，无法得到未知 IP 主机的 ACK 应答，久而久之就会占满服务端的 SYN 接收队列（未连接队列），使得服务器不能为正常用户服务。
避免：①修改 Linux 内核参数，控制队列大小和当队列满时应做什么处理。如设置SYN_RCVD 状态连接的最大个数；
超出处理能时，对新的 SYN 直接回 RST，丢弃连接
②tcp_syncookies 的方式可以应对 SYN 攻击的方法： 「 SYN 队列」满之后，后续服务器收到 SYN 包，不进入「 SYN 队列」；计算出一个 cookie 值，再以 SYN + ACK 中的「序列号」返回客户端，服务端接收到客户端的应答报文时，服务器会检查这个 ACK 包的合法性。如果合法，直接放入到「 Accept 队列」。
如果持续不断地有连接因为 TCP 全连接队列溢出被丢弃，就应该调大 backlog 以及 somaxconn 参数。
1.如果「当前半连接队列」没超过「理论半连接队列最大值」，但是超过 max_syn_backlog - (max_syn_backlog >> 2)，那么处于 SYN_RECV 状态的最大个数就是 max_syn_backlog - (max_syn_backlog >> 2)；
2.如果「当前半连接队列」超过「理论半连接队列最大值」，那么处于 SYN_RECV 状态的最大个数就是「理论半连接队列最大值」；
当 max_syn_backlog > min(somaxconn, backlog) 时， 半连接队列最大值 max_qlen_log = min(somaxconn, backlog) * 2;
当max_syn_backlog < min(somaxconn, backlog) 时， 半连接队列最大值 max_qlen_log = max_syn_backlog * 2;
23.三次握手的异常情况分别是怎样的？
1.当客户端发起的 TCP 第一次握手 SYN 包，在超时时间内没收到服务端的 ACK，就会在超时重传 SYN 数据包，每次超时重传的 RTO(初始为１s) 是翻倍上涨的，直到 SYN 包的重传次数到达 tcp_syn_retries 值后，客户端不再发送 SYN 包。
2.当 TCP 第二次握手 SYN、ACK 包丢了后，客户端 SYN 包会发生超时重传，服务端 SYN、ACK 也会发生超时重传。客户端 SYN 包超时重传的最大次数，是由 tcp_syn_retries 决定的，默认值是 5 次；服务端 SYN、ACK 包时重传的最大次数，是由 tcp_synack_retries 决定的，默认值是 5 次。
3.如果第三次握手的 ACK，服务端无法收到，则服务端就会短暂处于 SYN_RECV 状态，而客户端会处于 ESTABLISHED 状态。由于服务端一直收不到 TCP 第三次握手的 ACK，则会一直重传 SYN、ACK 包，直到重传次数超过 tcp_synack_retries 值（默认值 5 次）后，服务端就会断开 TCP 连接。
而客户端则会有两种情况：
如果客户端没发送数据包，一直处于 ESTABLISHED 状态，然后经过 2 小时 11 分 15 秒才可以发现一个「死亡」连接，于是客户端连接就会断开连接。
如果客户端发送了数据包，一直没有收到服务端对该数据包的确认报文，则会一直重传该数据包，直到重传次数超过 tcp_retries2 值（默认值 15 次）后，客户端就会断开 TCP 连接
