计算机网络

OSI与TCP各层的结构和功能，都有哪些协议

五层协议的体系结构

应用层：

应用层(application-layer）的任务是通过应用进程间的交互来完成特定网络应用。应用层协议定义的是应用进程（进程：主机中正在运行的程序）间的通信和交互的规则。对于不同的网络应用需要不同的应用层协议。在互联网中应用层协议很多，如域名系统DNS，支持万维网应用的 HTTP协议，支持电子邮件的 SMTP协议等等。我们把应用层交互的数据单元称为报文。

运输层：

运输层(transport layer)的主要任务就是负责向两台主机进程之间的通信提供通用的数据传输服务。应用进程利用该服务传送应用层报文。“通用的”是指并不针对某一个特定的网络应用，而是多种应用可以使用同一个运输层服务。由于一台主机可同时运行多个线程，因此运输层有复用和分用的功能。所谓复用就是指多个应用层进程可同时使用下面运输层的服务，分用和复用相反，是运输层把收到的信息分别交付上面应用层中的相应进程。

网络层：

在 计算机网络中进行通信的两个计算机之间可能会经过很多个数据链路，也可能还要经过很多通信子网。网络层的任务就是选择合适的网间路由和交换结点， 确保数据及时传送。 在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送。在 TCP/IP 体系结构中，由于网络层使用 IP 协议，因此分组也叫 IP 数据报 ，简称 数据报。互联网是由大量的异构（heterogeneous）网络通过路由器（router）相互连接起来的。互联网使用的网络层协议是无连接的网际协议（Intert Prococol）和许多路由选择协议，因此互联网的网络层也叫做网际层或IP层。

数据链路层：

数据链路层(data link layer)通常简称为链路层。两台主机之间的数据传输，总是在一段一段的链路上传送的，这就需要使用专门的链路层的协议。 在两个相邻节点之间传送数据时，数据链路层将网络层交下来的 IP 数据报组装程帧，在两个相邻节点间的链路上传送帧。每一帧包括数据和必要的控制信息（如同步信息，地址信息，差错控制等）。

物理层：

物理层(physical layer)的作用是实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异。 使其上面的数据链路层不必考虑网络的具体传输介质是什么。“透明传送比特流”表示经实际电路传送后的比特流没有发生变化，对传送的比特流来说，这个电路好像是看不见的。

七层体系结构图

TCP/IP 三次握手、四次挥手

image-20210625174336945

三次握手（建立连接）：

一次握手：客户端发送带有SYN标志的数据包

二次握手：服务端发送带有SYN/ACK标志的数据包

三次握手：客户端发送带有ACK标志的数据包

1
2
3
4
5
6
7
8
9
位码即tcp标志位，有6种标示：SYN(synchronous建立联机) ACK(acknowledgement 确认) PSH(push传送) FIN(finish结束) RST(reset重置) URG(urgent紧急)Sequence number(顺序号码) Acknowledge number(确认号码)
第一次握手：主机A发送位码为syn＝1，随机产生seq number=1234567的数据包到服务器，主机B由SYN=1知道，A要求建立联机；

第二次握手：主机B收到请求后要确认联机信息，向A发送ack number=(主机A的seq+1)，syn=1，ack=1，随机产生seq=7654321的包；

第三次握手：主机A收到后检查ack number是否正确，即第一次发送的seq number+1，以及位码ack是否为1，若正确，主机A会再发送ack number=(主机B的seq+1)，ack=1，主机B收到后确认seq值与ack=1则连接建立成功。

FTP协议及时基于此协议。

三次握⼿的⽬的是建⽴可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，⽽三次握⼿最主要的⽬的就是双⽅确认⾃⼰与对⽅的发送与接收是正常的。

握手次数 客户端 服务端
第一次 什么也不能确定 确定：客户端发送正常，服务端接收正常
第二次 确定：客户端发送正常、接收正常；服务端发送、接收正常； 确定：客户端发送正常，服务端接收正常
第三次 确定：客户端发送正常、接收正常；服务端发送、接收正常； 确定：客户端发送正常、接收正常；服务端发送、接收正常；

为什么三次握手，两次握手行不行

两次握手无法确定，客户端的接收是否正常（是否需要）。

如果使用两次握手：

客户端在第一次发送请求的时候，因为网络问题阻塞，超过了超时时间还没有收到服务端发送回来的确认请求，则客户端认为请求丢失，再次发送建立连接的请求。

在第二次建立链接顺利完成后，服务端释放了这次的链接，然后这个时候才收到第一次发送的链接（网络阻塞），服务端认为这是一个新的连接，确认建立链接，然后立即发送了请求，那么这次的发送就是无效的而且占用了资源

为什么要回传SYN

接收端传回发送端所发送的 SYN 是为了告诉发送端，我接收到的信息确实就是你所发送的信号了。

四次挥手（断开连接）

image-20210625174607286

假设本次由客户端主动断开连接

第一次：客户端发送FIN（告诉服务端，我要关闭链接了）

第二次：服务端收到FIN后，发给服务端一个ACK，确认序号为收到的序号+1。

第三次：服务端关闭与客户端的连接，发送一个FIN给客户端

第四次：客户端发挥ACK确认报文，确认序号为收到的序号+1。

握手次数 客户端 服务端
第一次 确定：客户端已经没有任务了，关闭链接 确定：客户端要关闭链接
第二次 确定：服务端确认客户端可以关闭链接 确定：客户端要关闭链接
第三次 确定：服务端也没有任务了，服务端要关闭链接（这个过程可能服务端还有传输任务，所以要把确认过程和关闭过程分为两次握手） 确定：客户端要关闭链接，服务端要关闭链接
第四次 确定：客户端确认服务端可以关闭链接 确定：客户端关闭链接，服务端要关闭链接
2ML ack可能丢失，如果第四次ack丢失服务端会在2ML内在发送一次FIN 正式关闭

img

由于TCP连接是全双工的，因此每个方向都必须单独关闭，这个原则是当以防完成它的数据发送任务后，就能发送一个FIN包来终止这个方向的连接。

收到一个FIN包只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后，仍然能发送数据，首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。

四次挥手过程

  • 第一次挥手：客户端发送一个FIN包（FIN=1，seq=U）给服务器，用来关闭客户端到服务器端的数据传输，客户端进入FIN_WAIT_1状态（终止等待）
  • 第二次挥手：服务器端收到FIN包后，发送一个ACK包（ACK=1，ack=u+1，在随机产生一个值v 给seq）给客户端，服务器进入了CLOSE_WAIT状态（关闭等待）
  • 第三次挥手：服务器端发送一个FIN包（FIN=1，ACK=1，ack=u+1，在随机产生 一个w值给seq）给客户端，用来关闭服务器到客户端的数据传输，服务端进入了LAST_ACK（最后确定）状态
  • 第四次挥手：客户端接收FIN包，然后进入TIME_WAIT状态，接着发送一个ACK包（ACK=1，seq=u+1, ack = w+1） 给服务端，服务端确定序号，进入CLOSe状态，完成了四次挥手。

挥手中的状态

  • CLOSED：表示初始状态
  • ESTABLISHED：表示连接已经连接
  • FIN_WAIT：状态FIN_WAIT_1和FIN_WAIT_2都表示等待对方的FIN报文，这两个状态的区别是，当主动发送方给对方发送了断开请求时，就进入了FIN_WAIT_1状态，而到被动方在回应后，主动发送方就进入了FIN_WAIT_2。
  • FIN_WAIT_2：上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你，稍后再关闭连接
  • CLOSE_WAIT：这个状态的含义是 表示在等待关闭
  • LAST_ACK：在被动关闭放发送FIN报文后，最后等待对方的ACK报文，当收到了ACK报文后，就进入了CLOSE状态。

为什么TIME_WAIT状态还需要等待2MSL后才能返回CLOSE

这是因为虽然双方都同意了关闭连接，而且握手的4个报文也都协调和发送完毕，按道理可以直接回到CLOSE状态

但是因为我们需要假设网络是不可靠的，你无法保证你最后发送的ACK报文是会一定被对方收到，因此处于LAST_ACK状态下的socket可能会因为超时未收到ACK报文，而重发FIN报文，所以这个TIME_WAIT状态的作用就是用来重发可能丢失的报文。

详细：https://blog.csdn.net/qzcsu/article/details/72861891

TCP和UDP区别

特点 性能
类型 是否面向连接 传输可靠性 传输形式 传输效率 所属资源 应用场景 首部字节
TCP 面向连接 可靠 字节流 慢 多 要求通信数据可靠
（如文件和邮件）		 20-60
UDP 无连接 不可靠 数据报文端 快 少 要求通信速度快
（如域名转换）		 8个字节
性能
类型 拥塞控制 连接方式
TCP 有 一对一全双工通信
UDP 没有
在网络拥塞的情况下不会使源数据发送速率降低，适用于实时性（直播和视频会议）		 一对一、一对多、多对一和多对多的通讯方式

UDP在传输数据的时候不需要建立连接，远程主机收到UDP报文后不需要任何确认，但是传输效率快，所属资源少适合直播、电话、视频

TCP是面向连接的，通过三次握手来建立连接，而在在进行数据传递的时候，有去人、窗口、重传、拥塞控制机制，在数据传输完成后还会断开链接来节约系统资源，增大了开销。但是传输可靠，一般用于文件传输、发送和接收邮件、远程登录等场景。

说一下什么是XSS 攻击

XSS（Cross site Scripting）中文名称为：跨站脚本攻击。XSS的重点不在于跨站，而在于脚本攻击。

XSS原理：恶意攻击在web页面会插入一些恶意的script代码。当用户浏览页面的时候，那么嵌入到web页面中的script代码会执行，因此会达到恶意攻击用户的目的。

后端防范XSS攻击：

最简单直接的方法就是添加Filter过滤器。

实现Filter接口，调用filterChain的doFilter方法，在这里面对servletRequest进行Script、style、sql等

https://blog.csdn.net/qq_33578833/article/details/100742137

TCP协议如果保证可靠传输

停止等待协议

  • 每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组；
  • 在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认；

1) 无差错情况:

img

2) 出现差错情况（超时重传）:

img

停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认，就重传前面发送过的分组（认为刚才发送过的分组丢失了），使用自动重传请求ARQ协议或者连续ARQ协议。

3) 确认丢失和确认迟到

  • 确认丢失：确认消息在传输过程丢失
    img
    当A发送M1消息，B收到后，B向A发送了一个M1确认消息，但却在传输过程中丢失。而A并不知道，在超时计时过后，A重传M1消息，B再次收到该消息后采取以下两点措施：
    1. 丢弃这个重复的M1消息，不向上层交付。
    2. 向A发送确认消息。（不会认为已经发送过了，就不再发送。A能重传，就证明B的确认消息丢失）。
  • 确认迟到 ：确认消息在传输过程中迟到
    img
    A发送M1消息，B收到并发送确认。在超时时间内没有收到确认消息，A重传M1消息，B仍然收到并继续发送确认消息（B收到了2份M1）。此时A收到了B第二次发送的确认消息。接着发送其他数据。过了一会，A收到了B第一次发送的对M1的确认消息（A也收到了2份确认消息）。处理如下：
    1. A收到重复的确认后，直接丢弃。
    2. B收到重复的M1后，也直接丢弃重复的M1。

自动重传请求ARQ协议

停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认，就重传前面发送过的分组（认为刚才发送过的分组丢失了）。因此每发送完一个分组需要设置一个超时计时器，其重转时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式常称为自动重传请求ARQ。

优点： 简单

缺点： 信道利用率低

连续ARQ协议

连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方一般采用累计确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了。

优点： 信道利用率高，容易实现，即使确认丢失，也不必重传。

缺点： 不能向发送方反映出接收方已经正确收到的所有分组的信息。 比如：发送方发送了 5条 消息，中间第三条丢失（3号），这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落，而只好把后三个全部重传一次。这也叫 Go-Back-N（回退 N），表示需要退回来重传已经发送过的 N 个消息。

滑动窗口

滑动窗口是接收端进行的流量控制。流量控制是为了控制发送方的发送速率，保证接收方来得及接收信息。发送方和接收方都有一个缓存队列，接收方发送确认报文的时候都会携带上要求发送方的流量窗口大小。当接收方的缓存队列已经满的时候，接收方在发送确认报文的时候，会减小窗口大小，使发送发下一次发送更少的数据。因为这个窗口时动态改变大小的，所以叫滑动窗口。

流量控制

就是使用滑动窗口来实现流量控制

拥塞控制

拥塞控制也是对流量 的控制，是发送方主动发起的。拥塞控制主要是解决网络中的流量过大超过了资源所能利用的部分，对所有的主机、路由器 造成影响。就想一个红绿灯路口的车辆过多就会造成拥塞，这个时候就需要降级车辆的数量、增大数据传输速率。

TCP发送方会维持一个拥塞窗口（cwnd）的状态变量，一次性发送数据量的大小

TCP的拥塞控制采用了三种算法：慢开始、拥塞避免、快重传和快恢复。

慢开始：慢开始算法的思路是当主机开始发送数据时，如果⽴即把⼤量数据字节注⼊到⽹络，那么可能会引起⽹络阻塞，因为现在还不知道⽹络的符合情况。经验表明，᫾好的⽅法是先探测⼀下，即由⼩到⼤逐渐增⼤发送窗⼝，也就是由⼩到⼤逐渐增⼤拥塞窗⼝数值。cwnd初始值为1，每经过⼀个传播轮次，cwnd加倍。

拥塞避免： 拥塞避免算法的思路是让拥塞窗⼝cwnd缓慢增⼤，即每经过⼀个往返时间RTT就把发送放的cwnd加1.

快重传与快恢复：在 TCP/IP 中，快速重传和恢复（fast retransmit and recovery，FRR）是⼀种拥塞控制算法，它能快速恢复丢失的数据包。没有 FRR，如果数据包丢失了，TCP 将会使⽤定时器来要求传输暂停。在暂停的这段时间内，没有新的或复制的数据包被发送。有了 FRR，如果接收机接收到⼀个不按顺序的数据段，它会⽴即给发送机发送⼀个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并⽴即重传这些丢失的数据段。有了 FRR，就不会因为重传时要求的暂停被耽误。 　当有单独的数据包丢失时，快速重传和恢复（FRR）能最有效地⼯作。当有多个数据信息包在某⼀段很短的时间内丢失时，它则不能很有效地⼯作。

整体流程：

image-20200623214100440

image-20200623220009542

这个几个算法是相互联合在一起的。传输过程最开始使用的慢开始算法，然后到达阈值后使用拥塞避免算法，

为了防止cwnd增长过大引起网络拥塞，还需设置一个慢开始门限ssthresh状态变量，ssthresh的用法如下：

  • 当 cwnd < ssthresh时：使用慢开始算法
  • 当cwnd = ssthresh时：采用 慢开始或拥塞避免中的任意一种
  • 当 cwnd > ssthresh时：采用拥塞避免算法

在最开始的时候，有一个传输阈值，先进行慢开始算法，每一次传输完成（客户端接受到了ack）则cwnd翻倍，一直到阈值为止

  • 如果中间出现了超时（未收到ack）则cwnd变为1，ssthresh变为原来的75%，继续使用慢开始算法，知道cwnd=ssthresh

浏览器输入URL之后到现界面的过程，用了哪些协议

  1. 浏览器查找域名的ip地址——DNS协议
  2. 浏览器向web服务器发送一个http请求
    1. TCP协议建立连接
    2. IP协议，发送数据在网络层使用 ip协议
    3. OSPF（Open Shortest Path First）协议，开放的最短路径优先协议，路由器寻址
    4. ARP：路由器与服务器通信的时候，将ip地址转换为mac地址，需要使用ARP协议
    5. HTTP：在TCP建立完成后，使用HTTP协议访问网页
  3. 服务器处理请求（请求 处理请求&它的参数、cookies、生成一个HTML响应）
  4. 服务器发回一个HTML响应
  5. 浏览器解析显示HTML

HTTP1.0和HTTP1.1的主要区别

http1.0最早在网页中使用是1996年就，http1.1在1999年开始广泛应用于现在各大浏览器网络请求中，同时HTTP1.1也是目前使用最广泛的HTTP协议。

主要区别：

  1. 长链接：在HTTP1.0中，默认使用的是短连接，也就是每次请求都要重新建立一次连接。HTTP是基于TCP/IP协议的，每一次建立或断开连接都需要三次握手和四次挥手的开销，如果每次请求都要这样，开销比较大。因此最好维持一个长链接，使用长链接来发送多个请求。HTTP1.1开始，默认使用长链接，默认开启Connection： keep-alive。

    1. HTTP-1.1的持续连接有非流水线方式和流水线方式。
      1. 流水线方式：在客户接受到HTTP的响应报文之前能接着发送新的请求报文。
      2. 非流水线方式：是客户在收到前一个响应后才能发送下一个请求。

  2. 错误状态响应吗：在HTTP1.1中新增24个错误状态响应码

    例如：

    1. 409表示请求的资源与资源的当前状态发生冲突
    2. 410表示服务器上的某个资源被永久性删除

    常用：

    ​

    转态码 描述
    4XX 客户端错误
    404 服务器无法找到请求的资源
    400 服务器不理就请求的语法
    403 禁止访问，服务器拒绝访问
    405 资源被禁止，禁用请求中的指定方法
    401 未授权
    415 不支持的媒体类型
    5XX 服务端错误
    2XX 成功

  3. 缓存处理：在HTTP1.0中主要使用header中的If-Modified-Since（文件修改时间）,Expires（文件过期时间）来做为缓存判断的标准，HTTP1.1则引⼊了更多的缓存控制策略例如Entity tag（文件唯一标识符），If-Unmodified-Since, If-Match,If-None-Match（tag的key）等更多可供选择的缓存头来控制缓存策略

    ​ https://www.cnblogs.com/echolun/p/9419517.html

    img

img

  1. 带宽优化及网络连接的使用：HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象发送过来了，并且都不支持断点续传功能。，HTTP1.1则在请求头引⼊了range头域，它允许只请求资源的某个部分，即返回码是206（PartialContent），这样就⽅便了开发者⾃由的选择以便于充分利⽤带宽和连接。

    1. 断点续传
      HTTP1.0:不支持断点续传，如果请求被中断，则必须重新再次发送，对于大文件的下载和传输不友好，尤其是在网络不好的情况下
      HTTP1.1:支持断点续传，利用HTTP消息头使用分块传输编码，将实体主体分块传输。垮掉了还能捡起来，很棒。客户端在发送的时候在发送一个range字段，记录bytes字段，然后从这个位置开始传输

  2. Host头处理：
    HTTP1.0:认为每台服务器都绑定唯一的IP地址，因此请求消息的URL中并没有传递主机名
    HTTP1.1:随着虚拟机技术的发展，一台物理服务器上可以存在多个虚拟主机，并且共享一个IP地址，这就需要我们在请求时指明是那台主机了。所以HTTP1.1的请求消息和响应消息都应支持Host头域，如果请求消息中没有Host头域，会报错（400）

HTTP和HTTPS的区别

  1. 端口：

    http的URL由“http://”起始且默认使用端口80，而HTTPS的URL由“https://”起始且默认使⽤端⼝443。

  2. 安全性和资源消耗： HTTP协议运行在TCP之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS是运行在SSL/TLS之上的HTTP协议，SSL/TLS 运行在TCP之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS高，但是 HTTPS 比HTTP耗费更多服务器资源。

    • 对称加密：密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密算法有DES、AES等；
    • 非对称加密：密钥成对出现（且根据公钥无法推知私钥，根据私钥也无法推知公钥），加密解密使用不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢，典型的非对称加密算法有RSA、DSA等
img

上述过程就是两次HTTP请求（第一次非对称加密保证安全，第二次是对称加密保证速率），其详细过程如下：

1.客户端想服务器发起HTTPS的请求，连接到服务器的443端口；

2.服务器将非对称加密的公钥传递给客户端，以证书的形式回传到客户端

3.服务器接受到该公钥进行验证，就是验证2中证书，如果有问题，则HTTPS请求无法继续；如果没有问题，则上述公钥是合格的。（第一次HTTP请求）客户端这个时候随机生成一个私钥，成为client key,客户端私钥，用于对称加密数据的。使用前面的公钥对client key进行非对称加密；

4.进行二次HTTP请求，将加密之后的client key传递给服务器；

5.服务器使用私钥进行解密，得到client key,使用client key对数据进行对称加密

6.将对称加密的数据传递给客户端，客户端使用对称解密，得到服务器发送的数据，完成第二次HTTP请求。

HTTPS为什么要进行证书验证，不验证回出现什么问题

公钥如果任意在网络中传播，很可能被非法中间商截获然后自己在颁布自己的公钥给客户端，然后中间的传输就是用的非法中间商的公钥和私钥。

这个时候就需要验证公钥的合法性（验证证书）。

  • 服务器端先把自己的公钥给证书颁发机构，向证书颁发机构申请证书
  • 证书颁发机构自己也有一堆公钥和私钥。机构利用自己的私钥来解密Key1，通过服务端网址等信息生成一个证书签名，证书签名同样经过机构的私钥加密。证书制作完成后，机构把证书发送给服务端。
  • 当客户端向服务端请求通信的时候，服务端不再直接返回自己的公钥，而是把自己申请的证书返回给客户端。
  • 客户端收到证书以后，要做的第一件事就是验证证书的真伪，需要说明的是，各大浏览器和操作系统已经维护了所有权威证书机构的名称和公钥，所以客户端只需要知道是哪个机构颁发的证书，就可以从本地找到对应的机构公钥，解密出证书签名。

ping的过程

HTTP状态码

状态码分类：

分类 描述
1** 信息，服务器收到请求，需要请求者继续执行操作
2** 成功，操作被成功接收并处理
3** 重定向，需要进一步的操作以完成请求
4** 请求错误，请求包含语法错误或无法完成请求
5** 服务器错误，服务器在处理请求的过程中发生了错误

常见状态码：

状态码 状态码英文名称 描述
100 Continue 客户端应当继续发送请求
101 Switching Protocols 切换协议（只能切换到更高级的协议，例如，切换到HTTP的新版本协议）。
200 OK 请求成功。一般用于GET与POST请求
201 Created 已创建。成功请求并创建了新的资源
202 Accepted 已接受。已经接受请求，但未处理完成
203 Non-Authoritative Information 非授权信息。请求成功。但返回的实体头部元信息不在原始的服务器，而是一个副本（来自本地或者第三方的拷贝）
204 No Content 无内容。服务器成功处理了请求，但不需要返回任何实体内容，并且希望返回更新了的元信息。在未更新网页的情况下，可确保浏览器继续显示当前文档。
205 Reset Content 重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域
206 Partial Content 部分内容。服务器成功处理了部分GET请求
300 Multiple Choices 多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择
301 Moved Permanently 永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替
302 Found 临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI
303 See Other 查看其它地址。与301类似。使用GET和POST请求查看
304 Not Modified 未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源
305 Use Proxy 使用代理。所请求的资源必须通过代理访问
400 Bad Request 客户端请求的语法错误，服务器无法理解
401 Unauthorized 请求要求用户的身份认证（没有权限）
402 Payment Required 保留，将来使用
403 Forbidden 服务器理解请求客户端的请求，但是拒绝执行此请求（权限不足）
404 Not Found 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置”您所请求的资源无法找到”的个性页面
405 Method Not Allowed 客户端请求中的方法被禁止
406 Not Acceptable 服务器无法根据客户端请求的内容特性完成请求
408 Request Time-out 服务器等待客户端发送的请求时间过长，超时
500 Internal Server Error 服务器内部错误，无法完成请求
501 Not Implemented 服务器不支持请求的功能，无法完成请求
502 Bad Gateway 作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应
503 Service Unavailable 由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中
504 Gateway Time-out 充当网关或代理的服务器，未及时从远端服务器获取请求
505 HTTP Version not supported 服务器不支持请求的HTTP协议的版本，无法完成处理