TCP三次握手四次挥手、Http协议解答
1. TCP 三次握手和四次挥手
简单示意图：
- 客户端-发送带有SYN标志的数据包 一次握手-服务端
- 服务端-发送带有SYN/ACK标志的数据包 二次握手-客户端
- 客户端-发送带有ACK标志的数据包 三次握手-服务端
SYN（Synchronize Sequence Numbers）同步序列编号，是TCP/IP建立连接时使用的握手信号。
在客户端和服务端之间建立正常的TCP网络连接时，客户端首先发出一个SYN信息，服务端使用SYN-ACK应答表示接收到了这个消息，最后客户端再以ACK(Acknowledgement)消息响应。
这样在客户端和服务端之间才能建立起可靠的TCP连接。
1.1. 三次握手的原因
三次握手的目的是建立可靠的通信信道，让发送方和接收方确定自己与对方的发送和接收是正常的
- 第一次握手：Client什么都不能确认；Server确定了自己接收正常，对方发送正常
- 第二次握手：Client确认了自己发送、接收正常，对方发送、接收也正常；Server确认了自己接收正常，对方发送正常
- 第三次握手：Client确认了自己发送、接收正常，对方发送、接受也正常；Server确认了自己发送、接受正常，对方发送、接受也正常
1.2. 第二次握手传回了ACK，为什么还要传回SYN
ACK是为了告诉客户端，我接收到的信息确实是你所发的信号，这表明客户端到服务端通信正常；而回传SYN是为了建立服务端到客户端的通信
1.3. 四次挥手的原因
断开一个TCP连接需要四次挥手
- 客户端-发送一个FIN，用来关闭客户端到服务端的数据传送
- 服务端-收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。和SYN一样，一个FIN将占用一个序号
- 服务端-关闭与客户端的连接，发送一个FIN给客户端
- 客户端-发回ACK报文确认，并将确认序号设置为收到序号加1
例如打电话，A和B通话，A告诉B：我说完了，你还有要说的吗；B说：好的，我也没啥要说，你可以挂了。
A先告诉B 我准备挂了，B收到后再告诉A 你可以挂了，B挂了，A断开
TCP，UDP协议的区别
| 连接类型 | 传输可靠性 | 传输形式 | 传输效率 | 所需资源 | 首部字节 | 应用场景 | |
|---|---|---|---|---|---|---|---|
| TCP | 面向连接 | 可靠 | 字节流 | 慢 | 多 | 20-60字节 | 对通信数据可靠(文件传输、邮件传输) |
| UDP | 无连接 | 不可靠 | 数据报文段 | 快 | 少 | 8个字节 | 对通信速度高(视频通话) |
UDP在传送数据之前不需要先建立连接，服务端在收到UDP报文后，不需要任何确认。特别适合即时通信，如视频通话、语音、直播
TCP在传送数据之前必须要先建立连接，数据传送完成之后要释放连接，在数据传送时，有确认、窗口、重传、拥塞控制机制，增加了开销和效率，提高了可靠性。
TCP协议如何保证可靠传输
- 应用数据被分割成TCP认为最适合发送的数据块
- TCP给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层
- 校验和：TCP将保持它首部和数据的校验和，目的是检测数据在传输的过程中的任何变化，如果收到段的检验和有差错，TCP将丢弃这个报文段，不确认收到此报文段
- TCP的接收端会丢弃重复的数据
- 流量控制(滑动窗口协议实现)：TCP连接的每一方都有固定大小的缓存空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方数据，能提示发送方降低发送的速率，防止丢包。
- 拥塞控制：当网络拥塞时，减少数据的发送
- 超时重传：当TCP发出一个段后，它启动一个定时器，等待接收端确认收到这个报文段。如果未收到确认，将重发这个报文段
ARQ协议
**自动重传请求(Automatic Repeat-reQuest)**：是OSI模型中数据链路层和传输层的错误纠正协议之一，它通过使用确认和超时这个两个机制，在不可靠服务的基础上实现可靠的信息传输，如果发送方在发送后一段时间之内没有收到确认帧，它通常会重新发送，ARQ包括 停止等待ARQ协议 和 连续ARQ协议
停止等待ARQ协议
停止等待协议是为了实现可靠传输的，它的基本原理就是每发完一个分割就停止发送，等待对方确认(回复ACK)。如果过了一段时间(超时时间后)，还是没有收到ACK确认，说明没有发送成功，需要重新发送，直到收到确认后再发下一个分组
- 优点：简单
- 缺点：信道利用率低，等待时间长
- 无差错情况
发送方发送分组 接收方在规定时间之内收到并且回复确认 发送方再次发送 - 出现差错情况（超时重传）
停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认，就重传前面发送过的分组认为刚才发送过的分组丢失了。因此每发送完一个分组需要设置一个超时计时器，其重传时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式称为 自动重传请求ARQ。
在停止等待协议中若收到重复分组，就丢弃该分组，但同时还要发送确认。 - 确认丢失和确认迟到
- 确认丢失：确认消息在传输过程丢失。当A发送M1消息，B收到后，B向A发送一个M1确认消息，但却在传输过程中丢失，而A并不知道于是在超时计时过后重传M1消息，B再次收到该消息后采取以下两点措施：1.丢弃这个重复的M1消息，不向上层交付；2.向A发送确认消息。
- 确认迟到：确认消息在传输过程中迟到。A发送M1消息，B收到并发送确认。在超时时间内没有收到确认消息。
连续ARQ协议
可提高信道利用率，发送维持一个发送，凡是位于发送窗口之内的分组可连续发送出去，而不需要等待对方确认，接收方一般采用累积确认，对按序到达的最后一个分组发送确认，表明到这个分组位置的所有分组都已经正确收到了
游览器URL访问流程
状态码
| 类别 | 含义 | |
|---|---|---|
| 1XX | Informational（信息性状态码） | 接收的请求正在处理 |
| 2XX | Success（成功状态码） | 请求正常处理完毕 |
| 3XX | Redirection（重定向状态码） | 需要进行附加操作以完成请求 |
| 4XX | Client Error（客户端错误状态码） | 服务器无法请求 |
| 5XX | Server Error（服务器错误状态码） | 服务器处理请求出错 |
HTTP长连接、短连接
在HTTP/1.0中默认使用短连接。客户端和服务器每进行一个Http操作，就建立一次连接，任务结束就中断连接。
而从Http/1.1起默认使用长连接，用以保存连接特性。使用长连接的Http协议，会在响应头加入这行代码Connection:keep-alive
在使用长连接的情况下。当一个网页打开完成之后，客户端和服务端直接用于传输Http数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，他有一个保持时间，可以在不同的服务器软件中设定这个时间。实现长连接需要客户端和服务端都支持长连接。Http协议的长连接和短连接，实质上是TCP协议的长连接和短连接
Http是不保存状态的协议，如何保持用户状态
Http是一种无状态协议，也就是说Http协议自身不对请求和响应直接的通信状态进行保存。Session的主要作用就是通过服务端记录用户的状态。服务端保存Session的方法(内存和数据库)。通过在Cookie中附加一个Session ID来实现跟踪
Cookie被禁用怎么办？ 最常用的就是利用URL重写把Session ID直接附加在URL路径的后面
Cookie和Session的区别
Cookie和Session都是用来跟踪浏览器用户身份的会话方式，但两者的应用场景不一样。Cookie数据保存在客户端，Session数据保存在服务端
Cookie一般用来保存用户信息，场景：在Cookie中保存已经登录过的用户信息，将Token放入Cookie中，下次登录的时候根据Token值来确认用户
Session主要作用就是通过服务端记录用户的状态
Http1.0和Http1.1的主要区别
| Http1.0 | Http1.1 | |
|---|---|---|
| 连接方式 | 默认使用短连接，每次请求都要重新建立一次连接（Http是基于TCP/IP协议的，每一次建立或断开连接都需要三次握手四次挥手的开销） | 默认使用长连接，默认开启Connection：keep-alive（Http1.1的持续连接有非流水线方式和流水线方式。流水线方式就是客户端在收到Http响应报文之前就能接着发送新的请求报文。非流水线方式则是客户端在收到前一个响应后才能发送下一个请求） |
| 缓存处理策略 | 主要使用header里的If-Modified-Since,Expires来做缓存判断的标准 | 引入更多的缓存控制策略Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略 |
| 带宽优化及网络连接 | 客户端请求对象的一部分，服务器会将整个对象响应，并且不支持断点续传功能（浪费带宽） | 在请求头引入range头域，它允许只请求资源的某个部分，即返回码是206(Partial Content)（充分利用带宽和连接） |
| 错误状态响应码 | - | 新增了24个错误状态响应码 |
URI和URL的区别
- URI（Uniform Resource Identifier）是统一资源标志符，可以唯一标识一个资源
- URL（Uniform Resource Location）是统一资源定位符，可以提供该资源的路径，它是一种具体的URI，即URL可以用来标识一个资源，而且还指明了如何locate这个资源
URI的作用像身份证号一样，URL的作用更像家庭住址一样。URL是一种具体的URI，它不仅唯一标识资源，而且还提供定位该资源的信息
Http和Https的区别
- 端口：http的url由
http://起始且默认使用80端口；https的url由https://起始且默认使用443端口 - 安全性和资源消耗：http基于TCP/IP协议，所有的传输内容都是明文，客户端和服务端都无法验证对方的身份；https是运行在SSL/TLS之上的TCP/IP协议，所有传输内容都经过加密
Http安全性没有Https高，但Https比Http耗费更多的服务器资源
Https的加密为对称加密，但是对称加密的秘钥是用服务器方的证书进行了非对称加密
