一、HTTP协议
1、http定义
HTTP（HyperText Transfer Protocol，超文本传输协议）是一个请求 - 响应（Request to Response）协议，位于网络模型的应用层，基于传输层的?TCP?协议。
2、http请求-响应模型
其次，HTTP 报文是在客户端和服务器端传输的数据报文，由起始行（Start Line）、请求头部（Request Header）和请求主体（Request Body）构成，从类型上分为请求报文（Request Message）和响应报文（Response Message）。
HTTP 报文格式
3、http请求方法?
POST 和 GET 方法POST 和 GET 方法进行对比
序号 方法 说明 1 GET 请求服务器上的资源，请求体不会包含请求数据，参数可以通过 URL 传输。 2 POST 用户传输信息到服务器，请求方式类似 GET 请求，比如提交表单。 3 PUT 用户传输信息到服务器，请求方式类似 POST 请求，比如提交文件。 4 DELETE 请求服务器删除某个资源，和 POST 请求作用相反。 5 OPTIONS 查询 URL 支持的 HTTP 方法。 6 HEAD 请求方式类似 GET 请求，但是服务器不会返回消息体，一般用于检查网页是否被修改、检查 URL 是否有效。 （1）GET 请求主要是为了从服务器获取资源，POST 请求主要是为了向服务器发送资源。
（2）GET 请求是通过 URL 传参，形式是?
field = value，多个参数使用?&?进行分割，例如?http://127.0.0.1/login?username=xiaoming&password=123456。POST 请求是通过请求体传参，即信息存放到 Request Body 中。（3）GET 请求传输的信息量少，POST 请求能够传输的信息量多。
（4）GET 请求参数在 URL 明文，容易被爬虫直接获取，POST 请求参数不直接可见，安全性更高，例如在表单提交密码时，必须使用 POST 请求。
4、http状态码
状态码 状态码对应英文 说明 100 Continue 服务器收到了客户端的请求行和头部信息，告诉
客户端继续发送数据部分。200 OK 请求成功。 301 Permanently Moved 资源被永久转移了，请求将被重定向。 302 Temporarily Moved 资源被临时转移了，请求将被重定向。 404 Not Found 资源没找到。 500 Internal Server Error 服务器内部错误。
?二、传输层TCP / UDP协议
1、TCP与UDP的区别
TCP（Transmission Control Protocol，传输控制协议） UDP（User Datagram Protocol，用户数据报协议） 是否连接 面向连接 无连接 传输方式 面向字节流：直接以字节流形式传输 面向报文：对于应用程序交付的数据，添加首部之后就交付给 IP 层 首部格式 20 个字节的固定首部 只有 8 个字节 是否可靠 可靠传输，依靠流量控制和拥塞控制 不可靠传输 连接对象个数 一对一连接 支持一对一（点到点），一对多以及多对多传输 适用场景 要求可靠传输的场景，例如发送邮件和传输文件 对可靠性要求低，效率要求高的场景，例如 QQ 的视频通话 总结：
- TCP 协议面向连接并且可靠，UDP 协议无连接并且不可靠；
- 虽然 UDP 协议不可靠，但是在对数据完整性要求低，对传输速度要求高的场景，可以适用 UDP 协议。
2、TCP三次握手
tcp如何建立链接，三次握手过程
过程解析
首先从行为上分析，TCP 建立连接需要发送三次报文，也就是 "三次握手" 的过程。
我们定义发送报文的一方是客户端，接收报文的一方是服务器端。
首先服务器端处于监听（LISTEN）的状态，否则不会收到客户端发来的请求。
（1）第一次握手：客户端往服务器端发送一个请求建立连接报文，报文首部 SYN 标志位 = 1，给定一个初始的 Seq 序号 x。之后客户端进入 SYN_SEN（同步发送）状态；
（2）第二次握手：服务器端收到请求报文，如果同意建立连接，则向客户端发送确认报文。确认报文中 SYN 标志位 = 1，ACK 标志位 = 1，同时给定一个 Seq 序号 y，Ack 确认号 x+1，之后服务器端进入 SYN_RCVD（同步已发送）状态；
（3）第三次握手：客户端收到来自服务器端的确认报文之后，还需要向服务器端发送确认报文，报文首部 ACK 标志位 = 1，Ack 确认号为 y+1，发送之后客户端进入 ESTABLISHED（已建立连接）的状态。服务器端收到确认报文后，也会进入 ESTABLISHED 状态，在此之后，客户端和服务器端可以开始 TCP 通信了。
3、TCP三次握手的必要性
首先从定性角度来看，分析三次握手每个步骤的意义：
（1）第一次握手：客户端发送报文，服务器端接收报文，如果成功接收，说明客户端的发送能力、服务器端的接收能力符合预期；
（2）第二次握手：服务器端发送报文，客户端接收报文，如果成功接收。从客户端的角度来看：客户端的发送和接收能力符合预期，服务器端的发送和接收能力符合预期，可以建立连接。但是从服务器端的角度来看：客户端的发送能力符合预期（第一次握手），服务器端的接收能力符合预期（第二次握手），但是因为收不到客户端的反馈（无法获知第二次握手的报文是否成功抵达客户端），那么只能得出服务器端的发送能力和客户端的接收能力不一定符合预期的结论；
（3）第三次握手：客户端发送报文，服务器端接收报文，如果接收成功，从服务器端的角度来看：客户端的报文接收能力以及服务器端的报文发送能力都符合预期。
经过三次握手的过程，客户端和服务器端都明确对方以及自己能成功接收和发送信息，所以就可以开始正常通信。
如何两次握手情况会是怎样？分析如下：
如果 TCP 只有两次握手，如果服务器端发送的第一个请求建立连接的报文在某个网络节点长时间阻塞，等到连接释放之后才抵达服务器端。本来这是一个早就失效的报文，但是服务器端收到这个失效的请求建立连接报文之后，会误以为是客户端需要建立一个新的连接请求，于是向客户端发送 ACK 确认报文，同意建立连接，这时候因为已经完成了两次握手，所以新的连接就会建立成功，这种情况显然不符合预期。
如果是三次握手，客户端不会向服务器端发送 ACK 确认报文，所以服务器端超过最长等待时间后，会认为客户端没有要求建立请求，这个无效报文最终会失效。
4、TCP四次挥手
上面分析了 TCP 建立连接的过程，既然有建立连接，对应的也有断开连接。数据传输完成之后，客户端和服务器端保持通信状态会占用资源开销，所以需要断开连接，TCP 协议中断开连接也被称为 TCP 四次挥手。
（1）四次挥手过程模型图
四次挥手过程分析如下：
首先从行为上分析，TCP 断开连接总共需要发送四次报文，也就是 "四次挥手" 的过程。
我们定义发送报文的一方是客户端，接收报文的一方是服务器端。
上一章节中已经对三次握手过程做出了分析，在建立连接后到传输数据的整个过程，客户端和服务器端均处于 ESTABLISHED（监听）状态，之后四次挥手的过程如下：
（1）第一次挥手：客户端发送一个请求结束报文，其中 FIN 标志位设置为 1，报文中给定一个序列号 u，报文内容是?FINbit=1 seq=u，发送之后主动进入 FIN_WAIT 状态，等待服务器端的确认报文；（2）第二次挥手：服务器端收到 FIN 报文，会发送 ACK 确认报文，并且把客户端发送的序列号加一作为确认报文的确认号，表示已经收到了客户端的报文，所以报文内容是?
ACKbit=1 seq=v ack=u+1，之后进入 CLOSE_WAIT（关闭等待）状态。此时会通知应用层的进程，客户端已经不会再发送数据了。此时连接处于半关闭状态，如果服务器端发送数据，客户端还是需要接收。客户端收到第二次挥手的报文后，会进入 FIN_WAIT_2（等待结束）状态，等待服务器发送最后的终止连接报文；
（3）第三次挥手：服务器端把最后的数据发送之后，就开始向客户端发送请求结束报文，FIN 标志位设置为 1，确认号设置为 u+1，比较特殊的一点是报文中 ACK 标志位也是 1，报文内容是?
FINbit=1 ACKbit=1 seq=w ack=u+1，发送之后服务器端进入 LAST_ACK（最终确认）状态，等待客户端的确认报文。（4）第四次挥手：客户端收到服务器的请求断开连接报文后，必须还要发出一个确认报文，ACK 标志位设置为 1，并且序列号同上一报文的确认号，确认号同上一报文的序列号加一，报文内容是?
ACKbit=1 seq=u+1 ack=w+1，之后客户端进入 TIME_WAIT（时间等待）状态。因为不会再收到服务器端的报文，所以等待 2*MSL（最大报文段生存时间）之后，自动进入 CLOSED（关闭）状态。服务器端在收到客户端的第四次挥手报文后，立即进入 CLOSED（关闭）状态，表示结束本次 TCP 连接。
在向面试官分析整个流程的时候，我们可以将四次报文中的第一次和第二次看作一个整体，即是客户端发送请求结束报文以及收到对应响应。第三次和第四次又是一个整体，即服务器端发送请求结束报文并且收到客户端的响应。
(2) 四次挥手的必要性
前置说明：TCP 是双向通信的协议，客户端可以发送和接收数据，服务器端也可以发送和接收数据，也就是全双工通信模式。
第一次挥手时，服务器端收到了客户端的 FIN 请求结束报文，但是因为应用层的进程可能还需要传输一些数据，不能立即关闭 SOCKET，所以只能先给客户端发送一个 ACK 确认报文，让客户端有 "心理准备"。之后服务器端进入 CLOSE_WAIT 状态，这个状态是为了处理最后的一些数据，等待这些数据也传输完毕之后，服务器端再发送 FIN 请求结束报文，到这里就已经有三次挥手的步骤了。最后，因为服务器端也需要感知第三次挥手的报文是否成功传输到客户端，所以客户端还需要第四次挥手的报文，来作为确认。