HTTP和HTTPS的区别，以及HTTPS有什么缺点？
区别：
1.(从安全性方面) HTTP是以明文的方式在网络中传输数据，而HTTPS协议传输的数据则是经过TLS加密后的，HTTPS具有更高的安全性。
2.(从传输过程方面) HTTPS在TCP三次握手阶段之后，还需要进行SSL的handshake，协商加密使用的对称加密密钥。
3.(从所需环境方面) HTTPS协议需要服务端申请证书，浏览器端安装对应的根证书。
4.(从端口方面) HTTP协议端口是80，HTTPS协议端口是443。
HTTPS的优点：
HTTPS传输数据过程中使用密钥进行加密，所以安全性更高。
HTTPS可以认证用户和服务器，确保数据发送到正确的用户和服务器。
HTTPS的缺点：
1.HTTPS握手阶段时延较高。由于在进行HTTPS会话之前还需要进行SSL握手，因此HTTPS协议握手阶段时延增加。
- HTTPS部署成本高：一方面HTTPS协议需要使用证书来验证自身的安全性，所以需要购买CA证书；另一方面由于采用HTTPS协议需要进行加密的计算，占用CPU资源较多，需要的服务器配置或数目高。
HTTP为什么是无状态的？
状态指的是客户端和服务器在临时会话中产生的数据。
无状态协议是指协议对事务处理没有记忆能力。HTTP协议不像建立了Socket连接的两个终端，双方是互相通信的，HTTP的客户端只能通过请求服务器来获取相关内容或文件信息。
HTTP协议这种特性有优点也有缺点。优点在于解放了服务器，每一次请求“点到为止”不会造成不必要的连接占用；缺点在于每次请求会传输大量重复的内容信息。
当客户端发送对服务器的HTTP请求之后，服务器根据客户端的请求会将数据发送给客户端，但是发送完会立刻断开和客户端的连接，不会保持，也不会记录任何信息。
HTTP为什么是无连接的？
有连接无连接指的都是TCP连接。
每一个访问都是无连接的，服务器挨个处理访问队列里的访问，处理完一个就关闭连接，然后处理下一个。无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。
TCP/IP的五层模型？
从上到下：应用层，传输层，网络层，数据链路层，物理层
为什么需要TCP协议？
因为IP层是不可靠的，它不保证网络包的交付，不保证网络包的按序交付、也不保证网络包中的数据的完整性。如果需要保障网络数据包的可靠性，那么就需要由上层（传输层）的TCP协议来负责。
因为TCP是一个工作在传输层的可靠数据传输的服务，它能确保接收端接收的网络包是无损坏、无间隔、非冗余和按序的。
TCP的三次握手？
第三次握手是可以携带数据的，前两次握手是不可以携带数据的。
为什么要三次握手？（为什么三次握手才可以初始化Socket、序列号和窗口大小并建立TCP连接）
1.三次握手才可以阻止重复历史连接的初始化（主要原因）
首要原因是为了防止旧的重复连接初始化造成混乱。客户端连续发送多次SYN建立连接的报文，在网络拥堵的情况下：
(1)一个旧SYN报文比最新的SYN报文早到达了服务端；
(2)那么此时服务端就会回一个SYN+ACK报文给客户端；
(3)客户端收到后可以根据自身的上下文，判断这是一个历史连接（序列号过期或超时），那么客户端就会发送RST报文给服务端，表示中止这一次连接。
2.同步双方初始序列号
TCP协议的通信双方，都必须维护一个序列号，序列号是可靠传输的一个关键因素，它的作用：
(1) 接收方可以去除重复的数据；
(2) 接收方可以根据数据包的序列号按序接收；
(3) 可以标识发送出去的数据包中哪些是已经被对方收到的。
可见，序列号在TCP连接中占据着非常重要的作用，所以当客户端发送携带初始序列号的SYN报文的时候，需要服务端回一个ACK应答报文，表示客户端的SYN报文已被服务端成功接收，那当服务端发送初始序列号给客户端的时候，依然也要得到客户端的应答回应，这样一来一回，才能确保双方的初始序列号能被可靠的同步。
3.避免资源浪费
如果只有两次握手，当客户端的SYN请求连接在网络中阻塞，客户端没有接收到ACK报文，就会重新发送SYN，由于没有第三次握手，服务器不清楚客户端是否收到了自己发送的建立连接的ACK确认信号，所以每收到一个SYN就只能先主动建立一个连接。如果客户端的SYN阻塞了，重复发送多次SYN报文，那么服务器在收到请求后就会建立多个冗余的无效链接，造成不必要的资源浪费。
两次握手不行么？
如果是两次握手连接，就不能判断当前连接是否是历史连接，三次握手则可以在客户端（发送方）准备发送第三次报文时，客户端因为有足够的上下文来判断当前连接是否是历史连接：
(1)如果是历史连接（序列号过期或超时），则第三次握手发送的报文是RST报文，以此中止历史连接；
(2)如果不是历史连接，则第三次发送的报文是ACK报文，通信双方就会成功建立连接；
两次握手只保证了一方的初始序列号能被对方成功接收，没办法保证双方的初始序列号都能被确认接收。
两次握手会造成资源浪费。即两次握手会造成信息滞留情况下，服务器重复接收无用的连接请求SYN报文，而造成重复分配资源。
为什么不是四次握手？
四次握手其实也能够可靠的同步双方的初始化序号，但由于第二步和第三步可以优化成一步，所以就成了三次握手。
TCP为什么挥手需要四次？
(1) 关闭连接时，客户端向服务端发送FIN时，仅仅表示客户端不再发送数据了但还是能接收数据。
(2) 服务器收到客户端的FIN报文时，先回一个ACK应答报文，而服务端可能还有数据需要处理和发送，等服务端不再发送数据时，才发送FIN报文给客户端表示同意现在关闭连接。
从上面过程可知，服务端通常需要等待完成数据的发送和处理，所以服务端的ACK和FIN一般都会分开发送，从而比三次握手多了一次。
两个MSL指的是什么？为什么TIME_WAIT等待的时间是2MSL？
MSL是Maximum Segment Lifetime，报文最大生存时间，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。因为TCP报文是基于IP协议的，而IP头中有一个TTL字段，是IP数据报可以经过的最大路由数，每经过一个处理它的路由器，此值就减1，当此值为0则数据报将被丢弃，同时发送ICMP报文通知源主机。
MSL与TTL的区别：MSL的单位是时间，而TTL是经过路由跳数。所以MSL应该要大于等于TTL消耗为0的时间，以确保报文已被自然消亡。
TIME_WAIT等待2倍的MSL，比较合理的解释是：网络中可能存在来自发送方的数据包，当这些发送方的数据包被接收方处理后又会向对方发送响应，所以一来一回需要等待2倍的时间。
比如如果被动关闭方没有收到断开连接的最后ACK报文，就会触发超时重发FIN报文，另一方接收到FIN后，会重发ACK给被动关闭方，一来一去正好2个MSL。
2MSL的时间是从客户端接收到FIN后发送ACK开始计时的。如果在TIME_WAIT时间内，因为客户端的ACK没有传输到服务端，客户端又接收到了服务端重发的FIN报文，那么2MSL时间将重新计时。
在Linux系统里2MSL默认是60秒，那么一个MSL也就是30秒。Linux系统停留在TIME_WAIT的时间为固定的60秒。
为什么需要TIME_WAIT状态？
主动发起关闭连接的一方，才会有TIME_WAIT状态。
需要TIME_WAIT状态，主要是两个原因：
(1) 防止具有相同四元组的旧数据包被收到；
经过2MSL这个时间，足以让两个方向上的数据包都被丢弃，使得原来连接的数据包在网络中都自然消失，再出现的数据包一定都是新建立连接所产生的。
(2) 保证被动关闭连接的一方能被正确的关闭，即保证最后的ACK能让被动关闭方接收，从而帮助其正常关闭。
TIME_WAIT过多有什么危害？
如果服务器有处于TIME_WAIT状态的TCP，则说明是由服务器方主动发起的断开请求。
过多的TIME_WAIT状态主要的危害有两种：
(1) 第一是内存资源占用；
(2) 第二是对端口资源的占用，一个TCP连接至少消耗一个本地端口。这个危害会造成严重的后果，端口的资源是有限的，一般可以开启的端口为32768~61000，如果发起连接的一方的TIME_WAIT状态过多，占满了所有端口资源，则会导致无法创建新连接。
35 张图解：被问千百遍的 TCP 三次握手和四次挥手面试题
为什么要进行TCP第四次挥手？
如果主动方及时发送ACK报文进行连接中断的确认，这时被动方就直接释放连接，进入可用状态。
服务器超时没有收到第三次握手会发什么报文？
当失败时服务器并不会重传ack报文，而是直接发送RTS报文段，进入CLOSED状态。这样做的目的是为了防止SYN洪泛攻击。
TCP第三次握手失败怎么办
面试官，不要再问我三次握手和四次挥手
TCP拥塞控制？以及达到什么情况的时候开始减慢增长的速度？
拥塞控制是防止过多的数据注入网络，使得网络中的路由器或者链路过载。流量控制是点对点的通信量控制，而拥塞控制是全局的网络流量整体性的控制。发送双方都有一个拥塞窗口——cwnd。
慢开始
最开始发送方的拥塞窗口为1，由小到大逐渐增大发送窗口和拥塞窗口。每经过一个传输轮次，拥塞窗口cwnd加倍。当cwnd超过慢开始门限，则使用拥塞避免算法，避免cwnd增长过大。拥塞避免
每经过一个往返时间RTT，cwnd就增长1。
在慢开始和拥塞避免的过程中，一旦发现网络拥塞，就把慢开始门限设为当前值的一半，并且重新设置cwnd为1，重新慢启动。（乘法减小，加法增大）。快重传
接收方每次收到一个失序的报文段后就立即发出重复确认，发送方只要连续收到三个重复确认就立即重传（尽早重传未被确认的报文段）。快恢复
当发送方连续收到了三个重复确认，就乘法减半（慢开始门限减半），将当前的cwnd设置为慢开始门限，并且采用拥塞避免算法（连续收到了三个重复请求，说明当前网络可能没有拥塞）。
采用快恢复算法时，慢开始只在建立连接和网络超时才使用。
达到什么情况的时候开始减慢增长的速度？
采用慢开始和拥塞避免算法的时候：
- 一旦cwnd>慢开始门限，就采用拥塞避免算法，减慢增长速度；
- 一旦出现丢包的情况，就重新进行慢开始，减慢增长速度。
采用快恢复和快重传算法的时候：
- 一旦cwnd>慢开始门限，就采用拥塞避免算法，减慢增长速度；
- 一旦发送方连续收到了三个重复确认，就采用拥塞避免算法，减慢增长速度。
TCP滑动窗口？
滑动窗口协议的基本原理就是在任意时刻，发送方都维持了一个连续的允许发送的帧的序号，称为发送窗口；同时，接收方也维持了一个连续的允许接收的帧的序号，称为接收窗口。发送窗口和接收窗口的序号的上下界不一定要一样，甚至大小也可以不同。不同的滑动窗口协议窗口大小一般不同。发送方窗口内的序列号代表了那些已经被发送，但是还没有被确认的帧，或者那些可以被发送的帧。
TCP和UDP的区别？
TCP是面向连接的、可靠的、基于字节流的传输层通信协议。
连接：
TCP是面向连接的传输层协议，即传输数据之前必须先建立好连接；
UDP无连接。服务对象：
TCP是点对点的两点间服务，即一条TCP连接只能有两个端点；
UDP支持一对一，一对多，多对一，多对多的交互通信。可靠性：
TCP是可靠交付：无差错，不丢失，不重复，按序到达；
UDP是尽最大努力交付，不保证可靠交付。拥塞控制，流量控制：
TCP有拥塞控制和流量控制保证数据传输的安全性；
UDP没有拥塞控制，网络拥塞不会影响源主机的发送效率。报文长度：
TCP是动态报文长度，即TCP报文长度是根据接收方的窗口大小和当前网络拥塞情况决定的；
UDP面向报文，不合并，不拆分，保留上面传下来报文的边界。首部开销：
TCP首部开销大，首部20个字节；
UDP首部开销小，8字节。（源端口，目的端口，数据长度，校验和）。
TCP和UDP的适用场景？
从特点上我们已经知道，TCP 是可靠的但传输速度慢，UDP 是不可靠的但传输速度快。因此在选用具体协议通信时，应该根据通信数据的要求而决定。
若通信数据完整性需让位与通信实时性，则应该选用TCP 协议（如文件传输FTP、重要状态的更新、HTTP/HTTPS等）；反之，则使用 UDP 协议（如视频传输、实时通信、DNS、SNMP等）。
UDP怎么实现可靠传输？
传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。最简单的方式是在应用层模仿传输层TCP的可靠性传输。下面不考虑拥塞处理，可靠UDP的简单设计。
(1) 添加seq/ack机制，确保数据发送到对端；
(2) 添加发送和接收缓冲区，主要是用户超时重传;
(3) 添加超时重传机制。
UDP如何实现可靠传输
DNS解析过程？
- 浏览器先检查自身缓存中是否有被解析过的这个域名对应的IP地址，如果有，解析结束。同时域名被缓存的时间也可通过TTL属性来设置。
- 如果浏览器缓存中没有（还没命中），浏览器会检查操作系统缓存中有没有对应的已解析过的结果。而操作系统也有一个域名解析的过程。在windows中可通过C盘里一个叫hosts的文件来设置，如果你在这里指定了一个域名对应的IP地址，那浏览器会首先使用这个IP地址。
但是这种操作系统级别的域名解析过程也被很多黑客利用，通过修改你的hosts文件里的内容把特定的域名解析到他指定的IP地址上，造成所谓的域名劫持。所以在windows7中将hosts文件设置成了readonly，防止被恶意篡改。 - 如果至此还没有命中域名，才会真正的请求本地域名服务器（LDNS）来解析这个域名，这台服务器一般在你的城市的某个角落，距离你不会很远，并且这台服务器的性能都很好，一般都会缓存域名解析结果，大约80%的域名解析到这里就完成了。
- 如果LDNS仍然没有命中，就直接跳到Root Server域名服务器请求解析。
- 根域名服务器返回给LDNS一个所查询域的主域名服务器（gLTD Server，国际顶尖域名服务器，如.com .cn .org等）地址。
- 此时LDNS再发送请求给上一步返回的gLTD。
- 接受请求的gLTD查找并返回这个域名对应的Name Server的地址，这个Name Server就是网站注册的域名服务器。
- Name Server根据映射关系表找到目标IP，返回给LDNS。
- LDNS缓存这个域名和对应的IP
- LDNS把解析的结果返回给用户，用户根据TTL值缓存到本地系统缓存中，域名解析过程至此结束。
DNS域名解析过程中的递归查询和迭代查询？
递归查询：
主机向本地域名服务器的查询一般都是采用递归查询。
所谓递归查询就是，如果主机所询问的本地域名服务器不知道被查询的域名的IP地址，那么本地域名服务器就以DNS客户的身份，向其它根域名服务器继续发出查询请求报文（即替主机继续查询），而不是让主机自己进行下一步查询。因此，递归查询返回的查询结果或者是所要查询的IP地址，或者是报错，表示无法查询到所需的IP地址。
迭代查询：
本地域名服务器向根域名服务器的查询采用迭代查询。
迭代查询的特点：当根域名服务器收到本地域名服务器发出的迭代查询请求报文时，要么给出所要查询的IP地址，要么告诉本地服务器：“你下一步应当向哪一个域名服务器进行查询”。然后让本地服务器进行后续的查询。根域名服务器通常是把自己知道的顶级域名服务器的IP地址告诉本地域名服务器，让本地域名服务器再向顶级域名服务器查询。顶级域名服务器在收到本地域名服务器的查询请求后，要么给出所要查询的IP地址，要么告诉本地服务器下一步应当向哪一个权限域名服务器进行查询。最后，知道了所要解析的IP地址或报错，然后把这个结果返回给发起查询的主机。
一次完整的HTTP请求过程？
- 对www.baidu.com这个网址进行DNS域名解析，得到对应的IP地址。
- 根据这个IP，找到对应的服务器，发起TCP的三次握手。
- 建立TCP连接后发起HTTP请求。
- 服务器响应HTTP请求，浏览器得到html代码。
- 浏览器解析html代码，并请求html中的代码资源（如js, css,图片等）（先得到html代码，才能去找这些资源）。
- 浏览器对页面进行渲染呈现给用户。
- 服务器关闭TCP连接。
HTTP状态码？
状态码一共分为五类：
1xx：处于中间状态，还需后续操作
2xx：成功收到报文并正确处理
“200 OK”：最常见的成功状态码，表示一切正常，客户端获得期许的处理结果。如果不是Head请求，那么在响应头中通常会有body数据。
“204 No Content"：这个的含义和"200"很相似，不同之处在于它的响应头中没有body数据。
"206 Partial Content"：是HTTP分块下载或断点续传的基础，在客户端发送"范围请求"、要求获取资源的部分数据时出现，它与200一样，也是服务器成功处理了请求，但body里的数据不是资源的全部，而是其中的一部分。状态码206通常还会伴随着头字段"Content-Range"，表示响应报文里body数据的具体范围，供客户端确认，例如"Content-Range: bytes 0-99/5000"，意思是此次获取的是总计5000个字节的前100个字节。
3xx：重定向到其他资源位置
"301 Moved Permanently"：“永久重定向”，意思是本地请求的资源以及不存在，使用新的URI再次访问。
"302 Found"："Moved Temporarily"，"临时重定向"，临时则所请求的资源暂时还在，但是目前需要另一个URI访问。
301和302通过在字段Location中表明需要跳转的URI。两者最大的不同在于一个是临时改变，一个是永久改变。举个例子，有时候需要将网站全部升级为HTTPS，这种永久性改变就需要配置永久的"301"。有时候晚上更新系统，系统暂时不可用，可以配置"302"临时访问，此时不会做缓存优化，第二天还会访问原来的地址。
"304 Not Modified"：运用于缓存控制。它用于 If-Modified-Since等条件请求，表示资源未修改，可以理解成"重定向已到缓存的文件"（即"缓存重定向"）。
4xx：请求报文有误，服务器无法处理
"400 Bad Request"：通用错误码，表示请求报文有错误，但是这个错误过于笼统。不知道是客户端还是哪里的错误，所以在实际应用中，通常会返回含有明确含义的状态码。
"403 Forbidden"：注意了，这一个是表示服务器禁止访问资源。原因比如涉及到敏感词汇、法律禁止等。当然，如果能让客户端有一个清晰的认识，可以考虑说明拒绝的原因并返回即可。
"404 Not Found"：这可能是我们都知道且都不想看到的状态码之一，它的本意是想要的资源在本地未找到从而无法提供给服务端，但是现在，只要服务器"耍脾气"就会给你返回404，而我们也无从得知后面到底是真的未找到，还是有什么别的原因。