1、HTTP
HyperText Transfer Protocol，用于传输HTML等内容的应用层协议，规定了浏览器和服务器之间如何通信以及通信时的数据格式
HTTPS 原理 （HTTPS = HTTP + SSL)
Http 是明文传输，不安全，
HTTPS 并不是新协议，而是让 HTTP 先和 SSL（Secure Sockets Layer）通信，再由 SSL 和 TCP 通信，也就是说 HTTPS 使用了隧道进行通信。通过使用 SSL，HTTPS 具有了加密（防窃听）、可靠认证（防伪装）和完整性保护（防篡改）三大特点。
SSL称为安全套接字层，它位于传输层和应用层之间，为 Https 提供加密，认证，和完整性保护等服务。
HTTPS 采用的加密方式
HTTPS 采用混合的加密机制，使用非对称密钥加密传输对称密钥来保证传输过程的安全性，之后使用对称密钥加密进行通信来保证通信过程的效率。如果单独使用非对称秘钥的话每次加密和解密的时间开销太大，如果单独使用对称加密的话，可靠性不够，容易被窃听拦截后破解，所以同时使用对称加密和非对称加密。
HTTPS 建立连接的具体过程：
1. client向server发送请求，然后连接到server的443端口，发送的信息主要是随机值1和客户端支持的加密算法。
2. server接收到信息之后给予client握手信息和数字证书，握手信息包括随机值2和匹配好的协商加密算法，而数字证书就是公钥。
3. 客户端解析证书，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随即值（预主秘钥），接下来是通过随机值1、随机值2和预主秘钥组装会话秘钥。然后通过证书的公钥加密会话秘钥。传送这个会话秘钥信息。
4. 服务端通过私钥解密得到随机值1、随机值2和预主秘钥，然后根据刚才协商好的加密算法组装成会话秘钥。
5. 客户端通过会话秘钥加密一条消息发送给服务端，主要验证服务端是否正常接受客户端加密的消息。
6. 同样服务端也会通过会话秘钥加密一条消息回传给客户端，如果客户端能够正常接受的话表明SSL层连接建立完成了。
HTTPS 的缺点
- 因为需要进行加密解密等过程，因此速度会更慢；
- 需要支付证书授权的高额费用。
HTTP 和 HTTPS 的区别
1、HTTPS 需要支付证书授权的高额费用
2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。（这个只是默认端口不一样，实际上端口是可以改的）
2、HTTP请求报文与响应报文格式
请求报文包含三部分：
a、请求行：包含请求方法、URI、HTTP版本信息
b、请求首部字段
c、请求内容实体
响应报文包含三部分：
a、状态行：包含HTTP版本、状态码、状态码的原因短语
b、响应首部字段
c、响应内容实体
a、请求行：包含请求方法、URI、HTTP版本信息
b、请求首部字段
c、请求内容实体
响应报文包含三部分：
a、状态行：包含HTTP版本、状态码、状态码的原因短语
b、响应首部字段
c、响应内容实体
3、Http协议中有哪些请求方式?
GET:用于请求访问已经被URI(统一资源标识符)识别的资源,可以通过URL传参给服务器
POST:用于传输信息给服务器,主要功能与GET方法类似,但一般推荐使用POST方式
PUT:传输文件,报文主体中包含文件内容,保存到对应URI位置
HEAD:获得报文首部,与GET方法类似,只是不返回报文主体,一般用于验证URI是否有效
DELETE:删除文件,与PUT方法相反,删除对应URI位置的文件
OPTIONS:查询响应URI支持的HTTP方法
4、在浏览器中输入url地址 ->> 显示主页的过程(面试常客)
打开一个网页，整个过程会使用哪些协议
图解（图片来源：《图解HTTP》）：
总体来说分为以下几个过程:
- DNS解析，将域名解析为ip地址，这个ip的查找过程又分成三种情况：浏览器缓存、路由器缓存、DNS缓存
- TCP连接，用到了IP协议、OSPF协议、ARP协议
- 发送HTTP请求 ，用到了HTTP协议，浏览器将用户的数据封装到cookies中，并将cookie封装到一个http请求中，如果网页中存在多个url请求，会在本次tcp连接请求中发起多次http请求。
- 服务器处理请求并生成一个html响应，将这个响应封装到一个http报文中并并返回HTTP报文
- 浏览器解析渲染页面
- 连接结束
ARP(Address Resolution Protocol)是地址解析协议
5、一次tcp连接中可以发送多少次 http 请求
如果是 http 1.0 则只能发一次，因为http1.0 是短连接，默认发送一次 http 请求就会断开连接，除非设置Connection: keep-alive
如果是 http 1.1 则可以发多次，因为http1.1 是长连接，只有客户端和服务器有一个发出断开连接的请求才会断开连接。
6、HTTP1.0和HTTP1.1的区别
1. 长连接
HTTP1.0 默认是短连接，发送一次 http 请求就会断开连接，除非设置Connection: keep-alive，而 在HTTP1.1中默认开启长连接keep-alive，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。
2. 节约带宽
HTTP 1.1 支持只发送header 信息和断点续传功能。节约了带宽。
3. HOST域
因为一个 iP 地址可能存在多台虚拟主机，所以发送请求时必须指明虚拟主机的主机号。
7、HTTP1.1 和 HTTP 2.0 的区别
1. 多路复用
HTTP2.0使用了多路复用的技术，做到同一个连接并发处理多个请求
2. 头部压缩
HTTP1.1不支持header数据的压缩，只会压缩消息主题，HTTP2.0支持对header的数据进行压缩，这样数据体积更小了，在网络上传输就会更快。
3. 服务器推送
也就是我们常说的预加载功能，允许服务器将当前网页所用的其他资源提前加载到浏览器，而不必等我们点击这个资源时再发起请求。这样可以降低延迟。
8、TCP三次握手
- 客户端–发送 SYN 标志位为 1 ， 序列号为 x 的数据包–一次握手–服务端，客户端进入同步发送状态
- 服务端–发送带有 SYN/ACK 标志的数据包–二次握手–客户端，服务端进入同步接收状态
- 客户端–发送带有带有 ACK 标志的数据包–三次握手–服务端，客户端进入连接状态，服务端收到这个确认报文后也进入连接状态。
为什么要三次握手，两次可以吗？
第三次握手的过程是客户端对服务器发送的确认连接进行确认，是为了防止失效的连接请求到达服务器后，让服务器错误打开连接。
客户端发送的连接请求如果在网络中滞留，那么就会隔很长一段时间才能收到服务器端发回的连接确认。客户端等待一个超时重传时间之后，就会重新请求连接。但是这个滞留的连接请求最后还是会到达服务器，如果不进行三次握手，每当服务器收到一个请求发送确认后就打开连接，那么服务器就会打开两个连接。如果有第三次握手，在已经建立连接的情况下，客户端会忽略服务器之后发送的对滞留连接请求的连接确认，不进行第三次握手，因此就不会再次打开连接。
如果第三次握手失败，即客户端发送的 ASK 确认包丢失怎么办
如果此时ACK在网络中丢失，那么Server端该TCP连接的状态为SYN_RECV，并且依次等待3秒、6秒、12秒后重新发送SYN+ACK包，以便Client重新发送ACK包。
Server重发SYN+ACK包的次数，可以通过设置/proc/sys/net/ipv4/tcp_synack_retries修改，默认值为5。 如果重发指定次数后，仍然未收到ACK应答，那么一段时间后，Server自动关闭这个连接。
但是Client认为这个连接已经建立，如果Client端向Server写数据，Server端将以RST包(用于强制关闭tcp连接)响应，方能感知到Server的错误。
RST是TCP 首部的一个志位，表示复位，用来异常的关闭连接，只要发送端觉得连接异常就会发送 RST 包，接收端收到这个包后就会马上断开连接。
什么是 syn - Flood 攻击
攻击方通过频繁的切换ip或者利用大量的 ip 向服务器发起大量的半连接请求，每次连接都只完成第二次握手，从而让服务器频繁的重发连接确认，大量的半连接信息将消耗服务器大量的系统资源和网络带宽，这样服务器就多余的资源接收正常客户的请求
解决办法：
- 缩短超时（SYN Timeout）时间
- 增加最大半连接数
- 过滤网关防护
目前最流行也是最好用的攻击方法就是使用SYN-Flood进行攻击，SYN-Flood也就是SYN洪水攻击。SYN-Flood不会完成TCP三次握手的第三步，也就是不发送确认连接的信息给服务器。这样，服务器无法完成第三次握手，但服务器不会立即放弃，服务器会不停的重试并等待一定的时间后放弃这个未完成的连接，这段时间叫做SYN timeout，这段时间大约30秒-2分钟左右。一个服务器若是处理这些大量的半连接信息而消耗大量的系统资源和网络带宽，这样服务器就不会再有空余去处理普通用户的正常请求(因为客户的正常请求比率很小)。这样这个服务器就无法工作了。
如果已经建立了连接，但是客户端突然出现故障了怎么办？
TCP还设有一个保活计时器，。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
9、TCP四次挥手过程
A 发送 FIN 标志位为 1， 序列号为 u 的连接释放报文，进入等待fin 报文的第一个阶段
B 收到之后发出确认，此时 TCP 属于半关闭状态，客户端在收到这个确认进入 等待 Fin 报文的第二个阶段。B 能向 A 发送数据但是 A 不能向 B 发送数据。
当 B 不再需要连接时，发送连接释放报文，FIN=1。服务端进入最后确认阶段
A 收到后发出确认，进入 TIME-WAIT 状态，等待 2 MSL（最大报文存活时间）后释放连接。
B 收到 A 的确认后释放连接。
为什么需要第四次挥手--（防止出现单方向没有释放连接）
假设只有三次挥手，也就是说服务端在发送完数据就向客户端发送一个带有 FIN 信号的报文，之后服务端彻底关闭连接，但是如果这个 FIN 报文丢失了，客户端没有收到这个报文， 客户端就会以为服务端仍有数据要发送，不会关闭连接。所以我们需要第四次挥手，让客户端收到 FIN 报文后发送一个确认报文，确认自己收到了关闭的信号，这样服务端在收到这个报文后就可以彻底关闭连接了。
TIME_WAIT
客户端接收到服务器端的 FIN 报文后进入此状态，此时并不是直接进入 CLOSED 状态，还需要等待一个时间计时器
设置的时间 2MSL。这么做有两个理由：
- 确保最后一个确认报文能够到达。如果 B 没收到 A 发送来的确认报文，那么就会重新发送连接释放请求报文，A 等待一段时间就是为了处理这种情况的发生。
- 等待一段时间是为了让本连接持续时间内所产生的所有报文都从网络中消失，使得下一个新的连接不会出现旧的连接请求报文。因为报文段有生存时间，当连接关闭时，有可能收到迟到的报文段。这时，若立马就建立新的连接（同一端口），那么新的连接就会接收迟到的报文，误以为是发给自己的。
如何统计time_wait的次数
两种方式，awk语句或者netstat｜grep time_wait｜wc -l
MSL
MSL是Maximum Segment Lifetime英文的缩写，中文可以译为“报文最大生存时间”，他是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。因为tcp报文（segment）是ip数据报（datagram）的数据部分，具体称谓请参见《数据在网络各层中的称呼》一文，而ip头中有一个TTL域，TTL是time to live的缩写，中文可以译为“生存时间”，这个生存时间是由源主机设置初始值但不是存的具体时间，而是存储了一个ip数据报可以经过的最大路由数，每经过一个处理他的路由器此值就减1，当此值为0则数据报将被丢弃，同时发送ICMP报文通知源主机。RFC 793中规定MSL为2分钟，实际应用中常用的是30秒，1分钟和2分钟等。
CLOSE_WAIT
服务器收到客户端发送来的 释放连接信号后，对这个信号进行确认，随后进入这个CLOSE_WAIT半关闭状态，此时服务端可以继续 向客户端发送数据，但是客户端不能向服务端发送数据。
10、TCP有哪些特性保证了其可靠性，其中哪一个可以去掉
TCP协议保证数据传输可靠性的方式主要有：
校验和、序列号、确认应答、超时重传、连接管理、流量控制、拥塞控制
- 校验和：保证数据的正确性
- 序列号：保证了针对数据包到达接收端主机顺序
确认应答和超时重传保证了 tcp 的可靠传输，连接管理中的三次握手和四次挥手保证了连接的正确建立和释放，流量控制和拥塞控制保证了客户端或者服务端能够来得及接受数据，并且不会出现网络拥堵。
- 确认应答：停止等待协议，发送之后等待收到应答。
- 超时重传：针对数据包丢失或者出现定时器超时
- 连接管理：三次握手与四次挥手
- 流量控制：针对避免网络拥堵时候；针对高效传输数据包的流动窗口的控制
- 拥塞控制：针对刚开始启动的时候避免一下子发送大量数据包而导致网络瘫痪的慢启动算法和拥塞控制。
哪一个可以去掉
拥塞控制可以去掉，因为在带宽较大，网络资源丰富时，流量控制已经约束了发送的速率，基本上不会造成网络拥塞。
11、是什么保证了TCP的 可靠传输
TCP 使用确认重传来实现可靠传输：如果一个已经发送的报文段在超时时间内没有收到确认，那么就重传这个报文段。
12、路由协议
自治系统内部的路由选择：RIP 和 OSPF自治系统间的路由选择：BGP
1. 内部网关协议 RIP（路由信息协议）
RIP 是一种基于距离向量的路由选择协议。距离是指跳数，直接相连的路由器跳数为 1。跳数最多为 15，超过 15 表示不可达。
RIP 按固定的时间间隔仅和相邻路由器交换自己的路由表，经过若干次交换之后，所有路由器最终会知道到达本自治系统中任何一个网络的最短距离和下一跳路由器地址。
RIP 协议实现简单，开销小。但是 RIP 能使用的最大距离为 15，限制了网络的规模。并且当网络出现故障时，要经过比较长的时间才能将此消息传送到所有路由器。
2. 内部网关协议 OSPF
开放最短路径优先 OSPF，是为了克服 RIP 的缺点而开发出来的。最短路径优先表示使用了 Dijkstra 提出的最短路径算法
SPF。所有路由器都具有全网的拓扑结构图，并且是一致的。相比于 RIP，OSPF 的更新过程收敛的很快。
3. 外部网关协议 BGP
BGP（Border Gateway Protocol，边界网关协议）
AS 之间的路由选择很困难，主要是由于：
互联网规模很大；
各个 AS 内部使用不同的路由选择协议，无法准确定义路径的度量；
AS 之间的路由选择必须考虑有关的策略，比如有些 AS 不愿意让其它 AS 经过。
BGP 只能寻找一条比较好的路由，而不是最佳路由。
每个 AS 都必须配置 BGP 发言人，通过在两个相邻 BGP 发言人之间建立 TCP 连接来交换路由信息。
13、拥塞控制，什么时候知道网络拥塞？
拥塞控制
慢开始算法、拥塞避免、快速重传、快速恢复
1. 慢开始与拥塞避免
发送的最初执行慢开始，令 cwnd = 1，发送方只能发送 1 个报文段；当收到确认后，将 cwnd 加倍，因此之后发送
方能够发送的报文段数量为：2、4、8 ...
注意到慢开始每个轮次都将 cwnd 加倍，这样会让 cwnd 增长速度非常快，从而使得发送方发送的速度增长速度过
快，网络拥塞的可能性也就更高。设置一个慢开始门限 ssthresh，当 cwnd >= ssthresh 时，进入拥塞避免，每个轮
次只将 cwnd 加 1。
如果出现了超时，则令 ssthresh = cwnd / 2，然后重新执行慢开始。
2. 快重传与快恢复
在接收方，要求每次接收到报文段都应该对最后一个已收到的有序报文段进行确认。在发送方，如果收到三个重复确认，那么可以知道下一个报文段丢失，此时执行快重传，立即重传下一个报文段。例如收到三个 M 2 ，则 M 3 丢失，立即重传 M3 。快恢复指的是发生快重传之后不必进入慢开始状态，而是将发送窗口减半，直接开始拥塞避免。
慢开始和快恢复的快慢指的是 cwnd 的设定值，而不是 cwnd 的增长速率。
流量控制：
流量控制是为了控制发送方发送速率，保证接收方来得及接收。通过滑动窗口机制可以实现这个发送速率的控制，发送窗口大小不能大于接受窗口，动态的改变窗口的大小，从而影响发送方的发送速率。将窗口字段设置为0，则发送方不能发送数据。可以通过持续计数器和发送探测报文可以打破僵。
什么时候知道网络拥塞
通过观察网络的吞吐量与网络负载间的关系
如果随着网络负载的增加，网络的吞吐量明显小于正常的吞吐量，那么网络就进入轻度拥塞的状况。
如果网络得吞吐量随着网络负载的增大反而下降，那么网络就可能进入拥塞状态。
14、UDP 和 TCP 的区别和特点
用户数据报协议 UDP（User Datagram Protocol）是无连接的，尽最大可能交付，没有拥塞控制，面向报文（对于应用程序传下来的报文不合并也不拆分，只是添加 UDP 首部），支持一对一、一对多、多对一和多对多的交互通信。
传输控制协议 TCP（Transmission Control Protocol）是面向连接的，提供可靠交付，有流量控制，拥塞控制，提供全双工通信，面向字节流（把应用层传下来的报文看成字节流，把字节流组织成大小不等的数据块），每一条 TCP 连接只能是点对点的（一对一）。之所以只能是一对一，我觉得可能是如果支持多播的话，那因为确认应答和超时重传机制，每次接收方都对发送发的数据进行确认应答，而如果一定时间没有收到接收方的确认，发送方也需要超时重传，这样如果在多播的情况下，如果有一个接收方因为各种原因没有发送应答信号，可能会影响整个多播网络的消息传输
tcp 和 udp 别适合什么应用？聊天要用什么？
TCP 应用于对效率要求相对低，但对准确性要求相对高；或者是有连接的场景 如：文件传输，发送邮件，远程登录
UDP 应用于对效率要求相对高，对准确性要求相对低的场景，比如：
1. 即时通信（QQ聊天，对数据准确性和丢包要求比较低，但速度必须快）；
2、在线视频（RTSP 速度一定要快，保证视频连续，但是偶尔花了一个图像帧，人们还是能接受的）
3、网络语音电话（VoIP 语音数据包一般比较小，需要高速发送，偶尔断音或串音也没有问题）等等
15、HTTP状态码
http的状态码：
服务器返回的 响应报文 中第一行为状态行，包含了状态码以及原因短语，用来告知客户端请求的结果。
100：continue，表示到目前位置都很正常，可以继续请求或者忽略这个回应。
200：OK
204：No content：请求已经成功处理，但是响应不包含主体部分。
206：partial content：返回请求的范围部分
301：move permanently：永久性重定向，一般是资源（网页等）被永久转移到其它URL
302：found：临时性重定向，一般是资源临时移动
303：see other:和302类似，但是明确要求用GET
304：not modified；请求首部包含一些条件，不满足则返回304
307：和302类似，但是明确要求浏览器不将POST变为GET
400：bad request:请求报文中存在语法错误，多半是前端提交的字段名称或者字段类型和后台的实体类不一样，或者前端提交的参数跟后台需要的参数个数不一致，导致无法封装。
401：unauthorized:表示请求需要有认证信息，如果已经请求过一次了，则说明认证失败。
403：forbidden:请求被拒绝，通常原因是服务器上某些文件或目录设置了权限，客户端权限不够
404：not found: 用户输入错误的链接，该链接指向的网页不存在。除此之外，也可以在服务器端拒绝请求且不想说明理由时使用。
405: method not allowed:方法不允许
500: Internal serval error:服务器处理请求时发生错误, 服务器内部错误（比如浏览器代理除了问题，ip，端口不对等）该状态码表明服务器端在执行请求时发生了错误。也有可能是Web应用存在的bug或某些临时的故障。
503: server unavarilable：服务器负载过大或者正在维护。
504，Gateway Timeout网关超时 服务器作为网关或代理，未及时从上游服务器接收请求。
16、get 和 post 的区别
以前我看在书上看到的区别的是：
- GET参数通过URL传递，而 URL 中传送的参数是有长度限制的，POST放在Request body中，大小没有限制。
- GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
- 对参数的数据类型，GET只接受ASCII字符，而POST没有限制。
- GET请求会被浏览器主动cache，而POST不会，除非手动设置。
- GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
- GET 是幂等的，执行多少遍不影响最终存储的结果。而
post每次调用都会创建新的资源。 - GET常用于获取资源的请求 、 POST常用于修改服务器资源的请求
但是我又看到网上博客说 它们的本质都是 TCP 链接，并无区别。但是由于 HTTP 的规定以及浏览器/服务器的限制，导致它们在应用过程中可能会有所不同。
get请求幂等性
17、虚拟专用网 VPN
由于 IP 地址的紧缺，一个机构能申请到的 IP 地址数往往远小于本机构所拥有的主机数。并且一个机构并不需要把所有的主机接入到外部的互联网中，机构内的计算机可以使用仅在本机构有效的 IP 地址（专用地址）。
有三个专用地址块：
10.0.0.0 ~ 10.255.255.255
172.16.0.0 ~ 172.31.255.255
192.168.0.0 ~ 192.168.255.255
VPN 使用公用的互联网作为本机构各专用网之间的通信载体。专用指机构内的主机只与本机构内的其它主机通信；虚拟指好像是，而实际上并不是，它有经过公用的互联网。
网络地址转换 NAT
专用网内部的主机使用本地 IP 地址又想和互联网上的主机通信时，可以使用 NAT 来将本地 IP 转换为全球 IP
18、Socket
(1) 服务端如何起一个Socket服务
(2) 如何限制Socket的最大连接数-设定一个集合和count变量 -这个集合用什么数据结构比较好
(3) Client发起连接请求是怎样的，何时才能发起请求
19、session 和 cookie 的区别：
HTTP是一种无状态的协议，为了分辨连接是谁发起的，需自己去解决这个问题。不然有些情况下即使是同一个网站每打开一个页面也都要登录一下。而Session和Cookie就是为解决这个问题而提出来的两个机制。
区别：
- 存储数据量方面：session 能够存储任意的 java 对象，cookie 只能存储 String 类型的对象且单个cookie 能够保存的数据 <= 4KB，大小限制是因为cookie需要在服务器和浏览器之间传递，如果大小太大会影响性能
- 一个在客户端一个在服务端。因Cookie在客户端所以可以编辑伪造，不是十分安全。所以不是很隐私的数据才会存在cookie中
- Session过多时会消耗服务器资源，大型网站会有专门Session服务器，Cookie存在客户端没问题。比较隐私的数据都存在session中
- 域的支持范围不一样，Cookie支持跨域访问，但是 Session 不支持跨域访问。比方说a.com的Cookie在a.com下都能用，而www.a.com的Session在api.a.com下都不能用，解决这个问题的办法是JSONP或者跨域资源共享/
20、DNS 域名系统(Domain Name System)
把网址转换成 ip 地址
域名服务器的结构：
根域名服务器，顶级域名服务器， 权限域名服务器，本地域名服务器
域名查询的方式：
1. 迭代查询
2. 递归查询