记录一些HTTP中常见的状态码 HTTP状态码是用以表示网页服务器超文本传输协议响应状态码的3位数字代码。分类含义1XX表示消息（不常用），这一类型的状态，表示请求已被接收，需要进行处理，这类响应是临时响应 ，只包含状态行和某些可选的响应头信息，并以空行结束2XX表示成功。这一类型的状态码，代表请求已成功被服务器接收、理解、并接受。3XX表示重定向。这类状态码需要客户端采取进一步的操作才能完成请求，通常这些状态码用来重定向，后续的请求地址（重定向目标）在本次响应的Location域中说明。4XX表示请求错误。这类的状态码代表客户端发生了错误，妨碍了服务器的处理。除非响应是一个HEAD请求，否则服务器就应该返回一个解释当期那错误状况的实体。以及这是临时的还是永久性的状况。这些状态码适用于任何请求方法，浏览器应当向用户显示任何包含此类错误响应中的实体内容。5XX表示服务器错误。这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生，也有可能是服务器意识到以当前的软硬件资源无法完成对请求的处理。除非这是一个HEAD请求，否则夫妻应当包含一个解释当前错误状态以及这个状况是临时的还是永久的解析信息实体，浏览器应当向用户展示任何当前响应中被包含的实体。2开头的常用状态码状态码状态描述200OK请求已成功，请求所希望的响应头或数据将随此响应返回202Accepted已接收，已经接收请求，但未处理完成206Partial Content部分内容，服务器成功处理了部分GET请求【断电续传】3开头的常用状态码状态码状态描述301Moved Permanently永久移动，请求的资源已被永久的移动到新的URI，返回信息会包含新的URI，浏览器会自动定向到新URI，今后任何新的请求都应使用新的URI代替。302Found临时移动，与301类似，但资源只是临时被移动，客户端应继续使用原有URI重定向： 从地址A跳转到地址B 。（百度百科请求的URL请求重新定到新的位置，页面重定向、域名重定向、路由重定向..等等）301 很多时候域名换了，到期了不想续费，所以永久移动到新域名上。302 就是临时跳转，最常见是登录的时候，点击登录如果校验成功，跳转到网站的首页。4开头的常用状态码服务器接收到了也完成了，但是跟你客户端预想不太一样。状态码状态描述400Bad Request客户端请求的语法错误，服务器无法理解401Unauthorized请求要求用户的身份认证403Forbidden服务器理解请求客户的请求。但是拒绝执行此请求404Not Found服务器无法根据客户端的请求找到资源（网页）403 表示资源不可用。服务器理解客户的请求，但拒绝处理它，通常由于服务器上文件或目录的权限设置导致的WEB访问错误5开头的常用状态码指的是服务器的错误，客户端发送的请求是没问题的。状态码状态描述500Internal Server Error服务器内部错误，无法完成请求502Bad Gateway充当网关或代理的服务器，从远端服务器接收到一个无效的请求。502有几种情况，一是配置问题服务器白名单无法进行上游服务通讯，二是请求过大超时。502 可能是内部存在大量的数据调用或交互时，网页内容提供方的一个或两个服务器，由于性能缺陷或程序错误，无法正常运行，使得网页上的内容无法被传输到用户的浏览器上，所以性能越高的服务器越少502出现。对于php中，造成502的原因常见的就是脚本执行超过timeout设置时间，或者timeout设置过大，导致php进程长时间不能被释放，没有空闲worker进程来接客。

TCP三次握手通信流程 流程客户端访问Web站点时，首先会通过DNS服务查询到域名的IP地址。然后浏览器生成HTTP请求，并通过TCP/IP协议发送web服务器，发送web服务器之前必须双方服务器先建立通讯，才能开始传输数据web服务器接收到请求后，会根据请求生成响应内容，并通过TCP/IP协议返回给客户端TCP的三次握手使用TCP协议进行通信的双方必须先建立连接，然后才能开始传输数据，为了确保连接双方可靠性，在双方建立连接时，TCP采用了3次握手策略。第一次握手客户端发送带有SYN标识的连接请求报文段，然后进入SYN_SEND状态，等待服务端确认。第二次握手服务端接受到客户端的SYN报文段后，需要发送ACK信息对这个SYN报文进行确认，同时，还要发送自己的SYN请求信息。服务端会将上述的信息放到一个报文段（SYN+ACK报文段）中，一并发送给客户端。此时服务端将会进入SYN_RECV状态。第三次握手客户端接受到服务端的SYN+ACK报文段后，会向服务发送ACK确认报文，这个报文段发送完毕后，客户端和服务端都进入ESTABLISHED状态，完成TCP的三次握手，可以进行数据传输了。2次就可以完成，为什么要进行3次握手?3次握手的目的是什么？最根本的目的客户端和通讯端要进行连接，要确认双方都能明确自己和对方收发能力都是正常的。第一次握手客户端发送网络包，服务端收到了。服务端得出结论 （ 客服端发送能力是正常，我自己的接收能力是正常 ，而客户端什么都不知道，只知道他发出了请求。）第二次握手所以服务端给客户端一个确认 ，发了一个包（确认+ 网络包的请求）给客户端。这样客户端得出结论 （ 服务端的接收能力是正常的 ，因为接收到我上一个数据， 服务端的发送能力也是正常的 ，因为它给我发来新的包。同时我也知道我自己客户端 前面一定是接收到我的包才给我发的新包, 确认我自己发送跟接收能力都正常的 。）客户端第一次发送的是正常的，第二次我收到了，我的接收能力也是正常的。第三次握手是因为服务端只知道 客户端的发送能力、和服务端的接收能力 不知道自己的发送能力行不行。当客户端再二次发送的时候，服务端接收到了，就知道了 客户端的接收能力，跟我的发送能力也是正常的 。经历3次握手客户端跟服务端都确认了自己的接收、发送是正常的，之后就可以正常的通信了。每次接收方的一方得到结论，发送的一方没有头绪，想要建立一个连接至少最少要3次或三次以上，2次达不到让双方都知道自己的接收、发送能力。每一次接收都知道对方发送、我方接收是正常的，每次都是关联的一个过程。能接收到上次我发送的数据才能知道这次的响应。现实举例小A跟小B都新买了手机，想要测试下2个的短信功能是否正常小A先发条信息给小B，说： “ 小B，你能收到我的短息吗？收到回复666 ”小B过了一会，收到了短信。证明了小A手机的发短信功能是ok的 ，自己的手机接收短信是OK的。然后小B想知道自己的发送短信行不行，所以回复了一条 ： “ 小A我收到了你信息，666，那你能收到我信息吗？收到给我回个 火箭”这时候小A也收到了小B的回复。其实在没收到短信之前，小A也不知道他的发送短信有没有发出去。但是一收到回复，就验证知道了。第一条肯定是发送成功 的，不然小B就回复给我回复了。同时小B也接收到了，他还发出来了，证明了我自己的接收跟发送都OK, 我也知道了小B的收发能力OK）。小A想了想... 我自己知道了他是没问题的。但是小B不知道他的发送OK是否知道。要是不回复的话，小B 不知道他短信是否发成功。所以小A最后回复了一条 ： “收到了，火箭火箭”。这时候小B就可以确认，自己的发送和小A的接收都没问题。这就是三次握手的经过。