一、OSI七层模型

参考链接：https://www.jianshu.com/p/9b9438dff7a2
参考模型是国际标准化组织(ISO)制定的一个用于计算机或通信系统间互联的标准体系，一般称为OSI参考模型或七层模型。

1）七层模型从上到下依次是

应用层：协议有HTTP 、FTP、 TFTP、 SMTP、 SNMP、 DNS 、TELNET 、HTTPS、 POP3、 DHCP
表示层：数据的表示、安全、压缩。格式有，JPEG、ASCll、DECOIC、加密格式等
会话层：建立、管理、终止会话。对应主机进程，指本地主机与远程主机正在进行的会话
传输层：定义传输数据的协议端口号，以及流控和差错校验。协议有：TCP 、UDP，数据包一旦离开网卡即进入网络传输层
网络层：进行逻辑地址寻址，实现不同网络之间的路径选择。协议有：ICMP 、IGMP、 IP（IPV4 IPV6）、 ARP、 RARP
数据链路层：建立逻辑连接、进行硬件地址寻址、差错校验等功能。将比特组合成字节进而组合成帧，用MAC地址访问介质，错误发现但不能纠正。
物理层：建立、维护、断开物理连接。

2）七层模型图示

七层模型1

七层模型2

3）七层模型传输数据过程

七层模型传输数据过程

二、TCP协议

TCP 全称传输控制协议，必须对数据的传输进行控制。

1. TCP 报文格式：

报文格式

• URG: 它为了标志紧急指针是否有效。
• ACK：标识确认号是否有效。
• PSH: 提示接收端应用程序立即将接收缓冲区的数据拿走。
• RST：它是为了处理异常连接的， 告诉连接不一致的一方，我们的连接还没有建立好， 要求对方重新建立连接。我们把携带 RST 标识的称为复位报文段。
• SYN: 请求建立连接; 我们把携带 SYN 标识的称为同步报文段。
• FIN: 通知对方, 本端要关闭连接了, 我们称携带 FIN 标识的为结束报文段。

6）16 位的紧急指针：按序到达是TCP协议保证可靠性的一种机制，但是也存在一些报文想优先被处理，这时就可以设置紧急指针，指向该报文即可，同时将紧急指针有效位置位1。
紧急
7）16 位窗口大小：如果发送方发送大量数据，接收方接收不过来，会导致大量数据丢失。然后接收方可以发送给发送发消息让发送方发慢一点，这是流量控制。接收方将自己接收缓冲器剩余空间的大小告诉发送方叫做16位窗口大小。发送发可以根据窗口大小来适配发送的速度和大小，窗口大小最大是 2 的 16 次方，及 64KB，但也可以根据选项中的某些位置扩展，最大扩展 1G。
8）16 位校验和：发送端填充，CRC校验。如果接收端校验不通过， 则认为数据有问题 (此处的检验和不光包含TCP首部也包含TCP数据部分)。

2. TCP可靠传输

TCP保证可靠传输的方式：

• 数据校验：TCP报文头有校验和，用于校验报文是否损坏
• 确认应答：接收方收到报文就会给发送方发送确认ACK报文
• 超时重传：发送方发送一段时间后没有收到确认就会重传
• 流量控制：当接收方来不及处理发送方的数据，能通过滑动窗口，提示发送方降低发送的速率，防止包丢失
• 拥塞控制：当网络拥塞时，通过拥塞窗口，减少数据的发送，防止包丢失

1）确认应答机制

确认应答机制

接收端收到一条报文后，向发送端发送一条确认ACK，此 ACK 的作用就是告诉发送端：接收端已经成功的收到了消息，并且希望收到下一条报文的序列号是什么。
这个ACK确认号就是期望的下一个报文的序号。每一个 ACK 都带有对应的确认序列号，意思是告诉发送者，我们已经收到了哪些数据，下一个发送数据应该从哪里开始。 如上图，主机 A 给主机 B 发送了 1-1000 的数据，ACK 应答，携带了 1001 序列号。告诉主机 A，我已经接受到了 1-1000 数据，下一次你从 1001 开始发送数据。

2） 超时重传

超时重传

ACK丢失

超时重发的时间如何确定？

这个时间的长短，随着网络环境的不同是有差异的。
如果超时时间设的太长，会影响整体的重传效率。如果超时时间设的太短，有可能会频繁发送重复的包。
TCP为了保证无论在任何环境下都能比较高性能的通信，因此会动态计算这个最大超时时间。Linux 中超时时间以500ms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍。如果重发一次之后，仍然得不到应答，等待2500ms后再进行重传。如果仍然得不到应答，等待4500ms进行重传。依次类推，以指数形式递增，当累计到一定的重传次数，TCP认为网络或者对端主机出现异常，强制关闭连接。

3）流量控制

流量控制(Flow Control)：TCP支持根据接收端的处理能力，来决定发送端的发送速度
接收端处理数据的速度是有限的，如果发送端发的太快，导致接收端的缓冲区被装满，这个时候如果发送端继续发送，就会造成丢包，然后引起丢包重传等等一系列连锁反应。

实现过程：

• 接收端将自己可以接收的缓冲区大小放入 TCP 首部中窗口大小字段，通过ACK确认报文通知发送端缓冲区大小
  • 窗口大小字段越大，说明网络的吞吐量越高，接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端
• 发送端接收到这个窗口后，就会减慢自己的发送速度
• 如果接收端缓冲区满了， 就会将窗口置为0。这时发送方不再发送数据，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。
  减慢

4）拥塞控制

虽然TCP有了滑动窗口能够高效可靠的发送大量的数据，但是如果在刚开始阶段就发送大量的数据，仍然可能引发问题，因为网络上有很多的计算机，可能当前的网络状态就已经比较拥堵，在不清楚当前网络状态下，贸然发送大量的数据是很有可能引起雪上加霜的，造成网络更加堵塞。

TCP 引入慢启动机制，先发少量的数据探探路，摸清当前的网络拥堵状态，再决定按照多大的速度传输数据。

拥塞控制

图中的cwnd为拥塞窗口，在发送开始的时候定义拥塞窗口大小为 1，每次收到一个 ACK 应答拥塞窗口加1。每次发送数据包的时候，将拥塞窗口和接收端主机反馈的窗口大小做比较，取较小的值作为实际发送的窗口。像上面这样的拥塞窗口增长速度，是指数级别的。

拥塞窗口

5）拥塞控制与流量控制的区别

拥塞控制：是防止过多的数据注入到网络中，可以使网络中的路由器或链路不致过载，是一个全局性的过程。
流量控制：是点对点通信量的控制，是一个端到端的问题，主要就是权衡发送端发送数据的速率，以便接收端来得及接收。

4. 三次握手

在正常情况下, TCP 要经过三次握手建立连接，四次挥手断开连接。

1）三次握手目的

三次握手其实就是指建立一个TCP连接时，需要客户端和服务器总共发送3个包。
进行三次握手的主要作用就是为了：
1）确认双方的接收能力和发送能力是否正常
2）指定自己的初始化序列号为后面的可靠性传送做准备。
实质上就是连接服务器指定端口，建立TCP连接，并同步连接双方的序列号和确认号，交换TCP窗口大小信息。

2）三次握手过程

刚开始客户端处于 Closed 的状态，服务端处于 Listen 状态。

三次握手

3次握手简要过程：

• A向B发送连接请求，并带有同步序列号SYN ———— A:我想和你通讯
• B收到连接请求并同意，给A发送确认应答ACK和同步序列号(SYN)标志位的数据段响应 ———— B:同意和你通讯
• A收到应答消息后，再给B发送一个确认应答ACK，确认已经收到B的消息了 ———— A:我收到你的同意消息了
  目的：若是2次握手，阻塞已失效的连接请求报文段突然又传到服务端B，B收到就建立连接，一直监听消息，浪费资源

3）为什么需要三次握手，两次不行吗？

先弄明白三次握手的目的是什么，能不能只用两次握手来达到同样的目的。
第一次握手：客户端发送网络包，服务端收到了。
服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
第二次握手：服务端发包，客户端收到了。
客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
第三次握手：客户端发包，服务端收到了。
服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。
因此，需要三次握手才能确认双方的接收与发送能力是否正常。

试想如果是用两次握手，则会出现下面这种情况：

第1次：如客户端发出连接请求，但因连接请求报文丢失而未收到确认
第2次：于是客户端再重传一次连接请求，后来收到了确认，建立了连接。数据传输完毕后，就释放了连接
重点：客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据，浪费资源。

4）三次握手过程中可以携带数据吗？

第一次、第二次握手不可以携带数据；第三次握手的时候，是可以携带数据的。

假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器，那他每次都在第一次握手中的 SYN 报文中放入大量的数据。因为攻击者根本就不理服务器的接收、发送能力是否正常，然后疯狂着重复发 SYN 报文的话，这会让服务器花费很多时间、内存空间来接收这些报文。

所以第一次握手不可以放数据，原因就是会让服务器更加容易受到攻击了。
而对于第三次的话，此时客户端已经处于 ESTABLISHED 状态。对于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以能携带数据也没啥毛病。

5. 四次挥手

1）四次挥手过程

• 终止一个TCP连接要经过四次挥手，这由TCP的半关闭（half-close）造成的。
• TCP半关闭，其实就是TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。
• TCP 连接的拆除需要发送四个包，因此称为四次挥手(Four-way handshake)
• 客户端或服务器均可主动发起挥手动作（即断开连接）。

四次挥手

第一次挥手：客户端发出连接释放报文段（FIN=1，序号seq=u），并停止再发送数据，主动关闭TCP连接，进入FIN_WAIT1（终止等待1）状态，等待服务端的确认。
第二次挥手：服务端收到FIN连接释放报文段后即发出ACK确认报文段（ACK=1，确认号ack=u+1，序号seq=v），服务端进入CLOSE_WAIT（关闭等待）状态，此时的TCP处于半关闭状态，客户端到服务端的连接释放。客户端收到服务端的确认后，进入FIN_WAIT2（终止等待2）状态，等待服务端发出的连接释放报文段。
第三次挥手：如果服务端也想断开连接了，服务端发出连接释放报文段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），服务端进入LAST_ACK（最后确认）状态，等待客户端的确认。
第四次挥手：客户端收到服务端的FIN连接释放报文段后，对此发出ACK确认报文段（ACK=1，seq=u+1，ack=w+1），客户端进入TIME_WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，客户端才进入CLOSED状态。

收到一个FIN只意味着在这一方向上没有数据流动。客户端执行主动关闭并进入TIME_WAIT是正常的，服务端通常执行被动关闭，不会进入TIME_WAIT状态。

四次挥手简要过程：

由于TCP连接是全双工的，因此每个方向必须单独关闭

• A给B发送FIN，停止A向B发送数据，但此时A还是能接收B的数据 ———— A：我不会再给你发数据了
• B收到A的消息，给A发送确认ACK消息 ———— B：我知道了
• B给A发送FIN，停止B向A发送数据 ———— B：我也不会再给你发数据了
• A收到B的消息，给B发送确认ACK消息 ———— A：我知道了

2）挥手为什么需要四次？

关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，“你发的FIN报文我收到了”。只有等到服务端所有的报文都发送完了，服务端才会发送FIN报文，因此不能一起发送。故需要四次挥手。

3）四次挥手释放连接时，等待2MSL的意义?

MSL：是“最长报文段寿命”，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。
等待2MSL的理由：

• 保证客户端发送的最后一个ACK报文段能够到达服务端。
  • 若客户端发送的最后一个ACK报文段丢失，使得服务端收不到对已发送的FIN+ACK报文段的确认，服务端超时重传FIN+ACK报文段，而客户端能在2MSL时间内收到这个重传的FIN+ACK报文段，接着客户端重传一次确认，重新启动2MSL计时器，最后客户端和服务端都进入到CLOSED状态，
  • 若客户端不等待2MSL时间，而是发送完ACK报文段后立即释放连接，则无法收到服务端重传的FIN+ACK报文段，服务端则会一直重传释放连接的FIN+ACK报文段，无法正常进入到CLOSED状态。
• 防止“已失效的连接请求报文段”出现在本连接中。
  • 客户端在发送完最后一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文段。

4）为什么TIME_WAIT状态需要经过2MSL才能返回到CLOSE状态？

理论上，四个报文都发送完毕，就可以直接进入CLOSE状态了，但是可能网络是不可靠的，有可能最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。

6. TCP全双工模式

TCP是全双工工作模式
全双工： 指可以同时进行信号的双向传输（A→B且B→A）。指A→B的同时B→A，是瞬时同步的。
半双工：指一个时间内只有一个方向的信号传输（A→B或B→A）

三、TCP和UDP的区别

TCP：传输控制协议，UDP：用户数据报协议
TCP和UDP都是传输层协议

区别：

• TCP 面向连接（如打电话要先拨号建立连接）；UDP 是无连接的，即发送数据之前不需要建立连接
• TCP 提供可靠的服务，通过 TCP 连接传送的数据，无差错，不丢失，不重复，且按序到达；
  UDP 尽最大努力交付，即不保证可靠交付，可能丢包
• TCP 面向字节流的服务，UDP 是面向报文的服务
• TCP有流量控制和拥塞控制，UDP没有，网络拥堵不会影响发送端的发送速率，因此UDP具有较好的实时性，工作效率较TCP协议高
• TCP 连接只能是一对一；UDP 支持一对一，一对多，多对一和多对多的通信
• TCP所需资源多，首部开销 20 字节；UDP 的首部开销小，只有 8 个字节
• TCP 的逻辑通信信道是全双工的可靠信道；UDP 则是不可靠信道

TCP应用：一般用于文件传输、发送接收邮件，如FTP(文件传输协议)、HTTP
UDP应用：即时通讯、网络语音、视频电话、实时游戏

四、HTTP

1. HTTP简介

1）定义

HTTP是超文本传输协议，它是基于 TCP 协议的应用层传输协议，简单来说就是客户端和服务端进行数据传输的一种规则。

2）特点

• 传输效率高：
  • 无连接：交换HTTP报文前，不需要建立HTTP连接
  • 无状态：数据传输过程中，不保存任何历史状态和信息，因此简化服务器的设计，使得更容易支持大量并发的HTTP请求
  • 传输格式简单：请求时，只需传送请求方法和路径
• 传输可靠性高：采用TCP作为运输层协议（TCP面向连接、可靠传输，交换报文前需要建立TCP连接）
• 兼容性好：支持B/S、C/S模式
• 灵活性高：HTTP允许传输任意类型的数据对象

http总结

2. HTTP工作方式

HTTP协议采用 【请求/响应】 的工作方式
具体流程：
1）服务器不断监听TCP端口80
2）客户端发送【建立连接】请求
3）双方建立TCP连接
4）客户端发送页面请求：【形式=HTTP请求报文】
5）服务器返回页面请求的响应结果：【形式=HTTP响应报文】
6）关闭TCP连接

http工作方式

3. HTTP报文

HTTP在应用层交互数据的方式 ：报文

HTTP的报文分为：请求报文（发送请求）、响应报文（响应请求）

3.1 请求报文格式

报文结构

1）请求行

作用：声明 请求方法 、主机域名、资源路径、协议版本
结构：请求行的组成 = 请求方法 + 请求路径 + 协议版本

GET /example.html HTTP/1.1 

备注：空格不能省

请求行

get/post区别

示例： 请求报文采用GET方法、

• URL地址 = http://www.tsinghua.edu.cn/chn/yxsz/index.htm；
• HTTP1.1版本

则请求行是：GET /chn/yxsz/index.htm HTTP/1.1

2）请求头

作用：声明客户端、服务器 / 报文的部分信息
使用方式：采用header(字段名)：value(值)的方式
常用请求头：

• 请求和响应报文的通用Header
  header

• 常见请求Header
  header

举例： (URL地址：http://www.tsinghua.edu.cn/chn/yxsz/index.htm）
Host：www.tsinghua.edu.cn (表示主机域名）
User - Agent：Mozilla/5.0 (表示用户代理是使用Netscape浏览器）

3）请求体

作用：存放需发送给服务器的数据信息，可选部分，如 GET请求就无请求数据

请求体

3.2 HTTP响应报文

1）报文结构

响应报文

其中，响应头、响应体与请求报文的请求头、请求体类似
请求报文和响应报文最大的不同在于状态行与请求行

2）状态行

组成：状态行有协议版本、状态码、状态信息组成，其中空格不能省

状态行

具体介绍

状态行示例：

• HTTP/1.1 202 Accepted(接受)
• HTTP/1.1 404 Not Found(找不到)

3）响应头

作用：声明客户端、服务器报文的部分信息
使用方式：采用header（字段名）：value（值）的方式
常用请求头：
（1）请求和响应报文的通用Header

header

响应header

4）响应体

作用：存放需返回给客户端的数据信息
使用方式：和请求体是一致的

响应体

5）响应报文总结

响应报文

4. HTTP1.1和HTTP1.0的区别

Http1.1 比 Http1.0 多了以下优点：

• HTTP1.0默认短连接，每次与服务器交互，都需要新开一个连接
  HTTP1.1默认持久连接，只要客户端服务端没有断开TCP连接，就一直保持连接，可以发送多次HTTP请求
• 引入更加多的请求头、响应头：如与身份认证、状态管理、 Cache缓存等机制相关的、HTTP1.0无host字段

5. HTTPS

HTTPS就是安全的HTTP协议（客户端与服务端的传输链路中进行加密）

HTTPS请求过程：

1）认证

• 服务器在使用HTTPS前，需要去CA机构申请数字证书：数字证书里包含证书持有者、证书有效期、服务器公钥 等信息
• 客户端请求服务器时，服务器返回私钥加密的证书给客户端
• 客户端用CA的公钥对证书解密，这个时候客户端会判断这个证书是否可信/有无篡改（因为CA是公信机构，会内置到浏览器或操作系统中，所以客户端会有公钥）

私钥加密，公钥解密叫做数字签名，这种方式可以查看有无篡改，到这里就解决了认证的问题，保证客户端是在跟真实的服务器进行通信

认证

2）加密

解决了认证的问题之后，就要解决加密问题，客户端与服务器的通讯内容在传输中不会泄漏给第三方

• 客户端从CA拿到数字证书后，就能拿到服务端的公钥
• 客户端生成一个key作为对称加密的密钥，用服务端的公钥加密后传给服务端
• 服务端用自己的私钥解密客户端的数据，得到对称加密的密钥
• 此时客户端和服务端都有此对称加密的密钥了，就可以使用此密钥发送和接收消息

https加密过程

HTTP和HTTPS的区别

http/https区别

1）安全性：HTTP 明文传输，数据都是未加密的，安全性较差，HTTPS（SSL+HTTP） 数据传输过程是加密的，安全性较好。
2）响应速度：HTTP 页面响应速度比 HTTPS 快，主要是因为 HTTP 使用 TCP 三次握手建立连接，客户端和服务器需要交换 3 个包，而 HTTPS除了 TCP 的三个包，还要加上 ssl 握手需要的 9 个包，所以一共是 12 个包。
3）耗费资源：HTTPS 其实就是建构在 SSL/TLS 之上的 HTTP 协议，所以，要比较 HTTPS 比 HTTP 要更耗费服务器资源。
4）端口：http 和 https 使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443。
5）费用：使用 HTTPS 协议需要到 CA（Certificate Authority，数字证书认证机构） 申请证书，一般免费证书较少，因而需要一定费用。

五、输入URL到页面呈现的过程

1）DNS域名解析：从url中提取出网站域名，使用 DNS 域名解析（域名和服务器 IP 对应关系保存在 hosts 文件中），找到对应服务器 IP地址
2）建立TCP连接：发起 TCP三次握手建立连接
3）发起HTTP请求：建立 tcp 连接后，发起请求 (包括端口路径，请求参数和各种信息)，获取服务器资源
4）响应HTTP请求：服务器响应 http 请求，将资源以http数据包封装，通过网络协议传输到前端
5）渲染：浏览器解析渲染页面
6）TCP关闭：四次挥手释放连接
总结：浏览器缓存——>DNS 域名解析——>TCP 连接——>HTTP 请求与响应——->DOM 渲染——>TCP 关闭

DNS域名解析过程：

1）先查看浏览器缓存
2）查看操作系统缓存
3）向本地域名服务器请求查询
4）本地域名去根域名服务器查询
5）本地域名服务器去顶级域名服务器查询
6）本地域名服务器去权威域名服务器查询

DNS域名解析

六、cookie、session

会话跟踪是Web程序中常用的技术，用来跟踪用户的整个会话。
常用的会话跟踪技术是Cookie与Session。Cookie通过在客户端记录信息确定用户身份，Session通过在服务器端记录信息确定用户身份

理论上，一个用户的所有请求操作都应该属于同一个会话。但由于HTTP协议是无状态的协议，一旦数据交换完毕，客户端与服务器端的连接就会关闭，再次交换数据需要建立新的连接。这就意味着服务器无法从连接上跟踪会话。即用户A购买了一件商品放入购物车内，当再次购买商品时服务器已经无法判断该购买行为是属于用户A的会话还是用户B的会话了。要跟踪该会话，必须引入一种机制。

共同点：

cookie 和 session 都是用来跟踪浏览器用户身份的会话方式，即认证鉴权

区别：

1）存储位置不同
cookie 数据存放在客户的浏览器上；session 数据放在服务器上。
2）隐私安全
cookie 不是很安全，对客户端是可见的，可以通过分析存放在本地的cookie并进行cookie欺骗，所以它是不安全的；
session存储在服务器上，对客户端是透明的，不存在敏感信息泄漏的风险。
3）有效期不同：
可以设置cookie的属性，达到使cookie长期有效的效果；
session只需关闭窗口该session就会失效，因而session不能达到长期有效的效果。
4）服务器压力不同
cookie保管在客户端，不占用服务器资源。对于并发用户十分多的网站，cookie是很好的选择。
session是保管在服务器端的，每个用户都会产生一个session。假如并发访问的用户十分多，会产生十分多的session，耗费大量的内存。
5）存储容量不同：
单个cookie保存的数据<=4KB，一个站点最多保存20个Cookie。
对于session来说并没有上限，但出于对服务器端的性能考虑，session内不要存放过多的东西，并且设置session删除机制。

七、网页加载慢的原因

1）本地问题：网络环境差、带宽不足，CPU或者是内存被占满等
2）DNS解析速度慢
3）加载某个资源太慢：资源在第三方网站上、资源太大了、资源使用的域名有问题
4）后端代码问题：代码冗余、数据库发生锁死、动态请求时间过长等
5）前端页面请求的资源过多：请求数太多、包含大量未经处理的图片
6）前端页面渲染太慢了

通过F12工具分析是前端还是后端响应慢问题：

• 如果服务器获取请求到返回的时间长 ———— 后端问题；
• 如果是请求获取数据很快，但是数据很多页面渲染需要时间 ———— 前端问题

八、如何判断是前端还是后端问题？

通过F12工具分析请求+响应：

• 请求url、参数等问题 ———— 前端问题；
• 响应结果正确 ———— 前端问题
• 响应结果错误 ———— 后端问题

九、post和get的区别？

1.传送方式：get通过地址栏传输，post通过报文传输
2.传送长度：get参数有长度限制（受限于url的长度），而post无限制
3.get产生一个TCP数据包：浏览器将header和data一起发出去，服务器响应200返回数据；
POST产生两个TCP数据包：浏览器先发送header，服务器响应100 continue，再发送data，服务器响应200返回数据；
4.get请求参数会被完整保留在浏览历史记录里，而post中的参数不会被保留
5.get：数据查询；post：数据添加、修改、删除

十、接口中常见的返回状态码

• 1xx：信息提示
• 2xx：服务器成功接收客户端请求，如200：OK
• 3xx：重定向
• 4xx：客户端错误，404：请求页面不存在
• 500：服务端错误