get请求报500_http请求和响应的全过程

写在最前面的话：

    最近心里总感觉怪怪的，也不知道为什么。直到今天我才发现我的公众号上有这么多用户呢。一个月因为种种原因没有更文章啦，心里总是过意不去，久等啦各位。以后尽我最大的努力更文章，哈哈哈！整理的这篇文章篇幅比较长，静下心慢慢看，相信会收获不少！

心里话

HTTP的两大特性：

1、无状态性(stateless)：指的是同一个客户端访问服务器两次，服务器是没有状态记录，不知道这个客户端是不是曾经访问过。同时也无法分辨不同的客户端

2、持久连接：在HTTP1.0的时候使用的是非持久连接，客户端必须为每个请求建立新的连接对象，每次请求都是两倍的RTT的开销。从HTTP1.1开始使用的是持久连接，在一段时间内保持客户端和服务器之间的连接，允许同一个连接中存在多次的数据请求和响应。

 2.1：持久连接的两种方式:

  2.1.1:非流水线方式：客户端在收到前一个响应后才能发出下一个请求

  2.1.2：流水线方式：客户端在收到HTTP的响应报文之前能接着发送新的请求报文

域名解析的原理：

1、一个域中的每个主机名与其IP地址的映射关系由这个域的DNS服务器负责管理，例如："www.it.org”、“ftp.it.org”、“blog.it.org”等主机名都由管理域“it.org”的DNS服务器进行管理，而不能由管理域“org”的DNS服务器进行管理。

2、每个管理域都必须在其直接父域的DNS服务器上注册该子域的名称和该子域的DNS服务器地址，例如，必须在管理域“org”的DNS服务器注册子域“it.org”和其DNS服务器的IP地址后，域名“it.org”才能真正被外界所认可

3、为了方便对顶级域名的统一管理，在顶级域名之上其实还有一个根域名，根域名用点(.)表示，例如，“www.it.org”也可以写为“www.it.org.”，“www.it.org.”中的最后的那个点(.)就表示根域名。Internet中的根域名由InterNIC(国际互联网络信息中心)集中管理，顶级域名和其下的域名则由拥有该域名的组织、公司和个人自己管理。

域名解析的两种方式

DNS有一个弊端，一个域名看上去只是对应一个单独的IP地址。还好有几种方法可以消除这个瓶颈：       

1>循环 DNS 是DNS查找时返回多个IP时的解决方案。举例来说，facebook.com实际上就对应了四个IP地址。        

2>负载平衡器是以一个特定IP地址进行侦听并将网络请求转发到集群服务器上的硬件设备。一些大型的站点一般都会使用这种昂贵的高性能负载平衡器。        

3>地理 DNS 根据用户所处的地理位置，通过把域名映射到多个不同的IP地址提高可扩展性。这样不同的服务器不能够更新同步状态，但映射静态内容的话非常好。        

4>Anycast 是一个IP地址映射多个物理主机的路由技术。美中不足的是Anycast与TCP协议适应的不是很好，所以很少应用在那些方案中。大多数DNS服务器使用Anycast来获得高效低延迟的DNS查找。

 浏览器与服务器建立TCP连接

16位源端口号：16位的源端口中包含初始化通信的端口。源端口和源IP地址的作用是标识报文的返回地址。16位目的端口号：16位的目的端口域定义传输的目的。这个端口指明报文接收计算机上的应用程序地址接口。32位序号：32位的序列号由接收端计算机使用，重新分段的报文成最初形式。当SYN出现，序列码实际上是初始序列码(Initial Sequence Number，ISN)，而第一个数据字节是ISN+1。这个序列号(序列码)可用来补偿传输中的不一致。32位确认序号：32位的序列号由接收端计算机使用，重组分段的报文成最初形式。如果设置了ACK控制位，这个值表示一个准备接收的包的序列码。4位首部长度：4位包括TCP头大小，指示何处数据开始。保留(6位)：6位值域，这些位必须是0。为了将来定义新的用途而保留。标志：6位标志域。表示为：紧急标志、有意义的应答标志、推、重置连接标志、同步序列号标志、完成发送数据标志。按照顺序排列是：URG、ACK、PSH、RST、SYN、FIN。16位窗口大小：用来表示想收到的每个TCP数据段的大小。TCP的流量控制由连接的每一端通过声明的窗口大小来提供。窗口大小为字节数，起始于确认序号字段指明的值，这个值是接收端正期望接收的字节。窗口大小是一个16字节字段，因而窗口大小最大为65535字节。16位校验和：16位TCP头。源机器基于数据内容计算一个数值，收信息机要与源机器数值 结果完全一样，从而证明数据的有效性。检验和覆盖了整个的TCP报文段：这是一个强制性的字段，一定是由发送端计算和存储，并由接收端进行验证的。16位紧急指针：指向后面是优先数据的字节，在URG标志设置了时才有效。如果URG标志没有被设置，紧急域作为填充。加快处理标示为紧急的数据段。选项：长度不定，但长度必须为1个字节。如果没有选项就表示这个1字节的域等于0。数据：该TCP协议包负载的数据。在上述字段中，6位标志域的各个选项功能如下。URG：紧急标志。紧急标志为"1"表明该位有效。ACK：确认标志。表明确认编号栏有效。大多数情况下该标志位是置位的。TCP报头内的确认编号栏内包含的确认编号(w+1)为下一个预期的序列编号，同时提示远端系统已经成功接收所有数据。PSH：推标志。该标志置位时，接收端不将该数据进行队列处理，而是尽可能快地将数据转由应用处理。在处理Telnet或rlogin等交互模式的连接时，该标志总是置位的。RST：复位标志。用于复位相应的TCP连接。SYN：同步标志。表明同步序列编号栏有效。该标志仅在三次握手建立TCP连接时有效。它提示TCP连接的服务端检查序列编号，该序列编号为TCP连接初始端(一般是客户端)的初始序列编号。在这里，可以把TCP序列编号看作是一个范围从0到4，294，967，295的32位计数器。通过TCP连接交换的数据中每一个字节都经过序列编号。在TCP报头中的序列编号栏包括了TCP分段中第一个字节的序列编号。FIN：结束标志。

三次握手

(1)第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。(2)第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。(3)第三次握手：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。简单来说，就是1、建立连接时，客户端发送SYN包(SYN=i)到服务器，并进入到SYN-SEND状态，等待服务器确认2、服务器收到SYN包，必须确认客户的SYN(ack=i+1),同时自己也发送一个SYN包(SYN=k),即SYN+ACK包，此时服务器进入SYN-RECV状态3、客户端收到服务器的SYN+ACK包，向服务器发送确认报ACK(ack=k+1),此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手，客户端与服务器开始传送数据。SYN攻击：在三次握手过程中，Server发送SYN-ACK之后，收到Client的ACK之前的TCP连接称为半连接(half-open connect)，此时Server处于SYN_RCVD状态，当收到ACK后，Server转入ESTABLISHED状态。SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server回复确认包，并等待Client的确认，由于源地址是不存在的，因此，Server需要不断重发直至超时，这些伪造的SYN包将产时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络堵塞甚至系统瘫痪。SYN攻击时一种典型的DDOS攻击，检测SYN攻击的方式非常简单，即当Server上有大量半连接状态且源IP地址是随机的，则可以断定遭到SYN攻击了，使用如下命令可以让之现行：#netstat -nap | grep SYN_RECV

 浏览器给web服务器发送一个http请求：

请求行：由请求方法、URL和HTTP协议版本3个字段组成，它们用空格分隔。例如，GET /index.html HTTP/1.1。HTTP协议的请求方法有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。而常见的有如下几种：

        1>GET：当客户端要从服务器中读取文档时，当点击网页上的链接或者通过在浏览器的地址栏输入网址来浏览网页的，使用的都是GET方式。GET方法要求服务器将URL定位的资源放在响应报文的数据部分，回送给客户端。使用GET方法时，请求参数和对应的值附加在URL后面，利用一个问号(“?”)代表URL的结尾与请求参数的开始，传递参数长度受限制。例如，/index.jsp?id=100&op=bind。通过GET方式传递的数据直接放在在地址中，所以GET方式的请求一般不包含”请求内容”部分，请求数据以地址的形式表现在请求行。地址中”?”之后的部分就是通过GET发送的请求数据，我们可以在地址栏中清楚的看到，各个数据之间用”&”符号隔开。显然这种方式不适合传送私密数据。另外，由于不同的浏览器对地址的字符限制也有所不同，一般最多只能识别1024个字符，所以如果需要传送大量数据的时候，也不适合使用GET方式。如果数据是英文字母/数字，原样发送，如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX为该符号以16进制表示的ASCII。

    2>POST：允许客户端给服务器提供信息较多。POST方法将请求参数封装在HTTP请求数据中，以名称/值的形式出现，可以传输大量数据，这样POST方式对传送的数据大小没有限制，而且也不会显示在URL中。POST方式请求行中不包含数据字符串，这些数据保存在“请求内容”部分，各数据之间也是使用”&“符号隔开。POST方式大多用于页面的表单中。因为POST也能完成GET的功能，因此多数人在设计表单的时候一律都使用POST方式，其实这是一个误区。GET方式也有自己的特点和优势，我们应该根据不同的情况来选择是使用GET还是使用POST。        

        3>HEAD：就像GET，只不过服务端接受到HEAD请求后只返回响应头，而不会发送响应内容。当我们只需要查看某个页面的状态的时候，使用HEAD是非常高效的，因为在传输的过程中省去了页面内容。 

请求头部：由关键字/值对组成，每行一对，关键字和值用英文冒号”:“分隔。请求头部通知服务器有关于客户端请求的信息，典型的请求头有：     

User-Agent：产生请求的浏览器类型。     

Accept：客户端可识别的内容类型列表。星号 “ * ” 用于按范围将类型分组，用 “ */* ” 指示可接受全部类型，用“ type/* ”指示可接受 type 类型的所有子类型。     

Host：要请求的主机名，允许多个域名同处一个IP地址，即虚拟主机。     

Accept-Language：客户端可接受的自然语言。     

Accept-Encoding：客户端可接受的编码压缩格式。     

Accept-Charset：可接受的应答的字符集。     

connection：连接方式(close 或 keepalive)。     

Cookie：存储于客户端扩展字段，向同一域名的服务端发送属于该域的cookie。

空行：最后一个请求头部之后是一个空行，发送回车符和换行符，通知服务器以下不再有请求头部。

请求数据：请求数据不在GET方法中使用，而在POST方法中使用。POST方法适用于需要客户填写表单的场合。与请求数据相关的最常使用的请求头部是Content-Type和Content-Length。

请求报文实例POST /search HTTP/1.1  Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint,application/msword, application/x-silverlight, application/x-shockwave-flash, */*  Referer: http://www.google.cn/  Accept-Language: zh-cn  Accept-Encoding: gzip, deflate  User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; TheWorld)  Host: www.google.cn  Connection: Keep-Alive  Cookie: PREF=ID=80a06da87be9ae3c:U=f7167333e2c3b714:NW=1:TM=1261551909:LM=1261551917:S=ybYcq2wpfefs4V9g;NID=31=ojj8d-IygaEtSxLgaJmqSjVhCspkviJrB6omjamNrSm8lZhKy_yMfO2M4QMRKcH1g0iQv9u-2hfBW7bUFwVh7pGaRUb0RnHcJU37y-FxlRugatx63JLv7CWMD6UB_O_r  hl=zh-CN&source=hp&q=domety

服务器的永久重定向响应

    服务器给浏览器响应一个301永久重定向响应，这样浏览器就会访问“http://www.facebook.com/” 而非“http://facebook.com/”。为什么服务器一定要重定向而不是直接发送用户想看的网页内容呢？其中一个原因跟搜索引擎排名有关。如果一个页面有两个地址，就像http://www.igoro.com/和http://igoro.com/，搜索引擎会认为它们是两个网站，结果造成每个搜索链接都减少从而降低排名。而搜索引擎知道301永久重定向是什么意思，这样就会把访问带www的和不带www的地址归到同一个网站排名下。还有就是用不同的地址会造成缓存友好性变差，当一个页面有好几个名字时，它可能会在缓存里出现好几次。

状态行：由HTTP协议版本、服务器返回的响应状态码和响应状态码的文本描述组成。(开发者手册：https://cloud.tencent.com/developer/section/1190118)状态代码由三位数字组成，第一个数字定义了响应的类别，且有五种可能取值。             

1xx：信息性状态码，表示服务器已接收了客户端请求，客户端可继续发送请求。           100 Continue                 

  101 Switching Protocols             

2xx：成功状态码，表示服务器已成功接收到请求并进行处理。                 

200 OK 表示客户端请求成功(一个成功的结果PUT还是DELETE往往不是一个200 OK而是一个204 No Content(或201 Created当资源被上传的第一次))                 

204 No Content 成功，但不返回任何实体的主体部分                 

206 Partial Content 成功执行了一个范围(Range)请求             

3xx：重定向状态码，表示服务器要求客户端重定向。                 

301 Moved Permanently 永久性重定向，响应报文的Location首部应该有该资源的新URL              

302 Found 临时性重定向，响应报文的Location首部给出的URL用来临时定位资源                 

303 See Other 请求的资源存在着另一个URI，客户端应使用GET方法定向获取请求的资源     

304 Not Modified 客户端发送附带条件的请求(请求首部中包含如If-Modified-Since等指定首部)时，服务端有可能返回304，此时，响应报文中不包含任何报文主 体。                         307 Temporary Redirect 临时重定向。与302 Found含义一样。302禁止POST变换为GET，但实际使用时并不一定，307则更多浏览器可能会遵循这一标准，但也依赖于浏览器具体实现             4xx：客户端错误状态码，表示客户端的请求有非法内容。                 

400 Bad Request 表示客户端请求有语法错误，不能被服务器所理解                

 401 Unauthonzed 表示请求未经授权，该状态代码必须与 WWW-Authenticate 报头域一起使用                 

403 Forbidden 表示服务器收到请求，但是拒绝提供服务，通常会在响应正文中给出不提供服务的原因                

 404 Not Found 请求的资源不存在，例如，输入了错误的URL             

5xx：服务器错误状态码，表示服务器未能正常处理客户端的请求而出现意外错误。                 500 Internel Server Error 表示服务器发生不可预期的错误，导致无法完成客户端的请求                 503 Service Unavailable 表示服务器当前不能够处理客户端的请求，在一段时间之后，服务器可能会恢复正常

响应头部：由关键字/值对组成，每行一对，关键字和值用英文冒号”:“分隔，典型的响应头有：          

Location：用于重定向接受者到一个新的位置。例如：客户端所请求的页面已不存在原先的位置，为了让客户端重定向到这个页面新的位置，服务器端可以发回Location响应报头后使用重定向语句，让客户端去访问新的域名所对应的服务器上的资源          

Server：包含了服务器用来处理请求的软件信息及其版本。它和 User-Agent 请求报头域是相对应的，前者发送服务器端软件的信息，后者发送客户端软件(浏览器)和操作系统的信息          

Vary：指示不可缓存的请求头列表          

Connection：连接方式 对于请求来说：close(告诉 WEB 服务器或者代理服务器，在完成本次请求的响应后，断开连接，不等待本次连接的后续请求了)。keepalive(告诉WEB服务器或者代理服务器，在完成本次请求的响应后，保持连接，等待本次连接的后续请求);对于响应来说：close(连接已经关闭); keepalive(连接保持着，在等待本次连接的后续请求);

Keep-Alive：如果浏览器请求保持连接，则该头部表明希望WEB 服务器保持连接多长时间(秒);例如：Keep-Alive：300;　　   

WWW-Authenticate：必须被包含在401 (未授权的)响应消息中，这个报头域和前面讲到的Authorization 请求报头域是相关的，当客户端收到 401 响应消息，就要决定是否请求服务器对其进行验证。如果要求服务器对其进行验证，就可以发送一个包含了Authorization 报头域的请求

空行：最后一个响应头部之后是一个空行，发送回车符和换行符，通知浏览器以下不再有响应头部。

响应数据：服务器返回给客户端的文本信息。 

响应报文示例HTTP/1.1 301 Moved PermanentlyCache-Control: private, no-store, no-cache, must-revalidate, post-check=0,pre-check=0Expires: Sat, 01 Jan 2000 00:00:00 GMTLocation: "http://www.facebook.com/">P3P: CP=”DSP LAW”Pragma: no-cacheSet-Cookie: made_write_conn=deleted; expires=Thu, 12-Feb-2009 05:09:50 GMT;path=/; domain=.facebook.com; httponlyContent-Type: text/html; charset=utf-8X-Cnection: closeDate: Fri, 12 Feb 2010 05:09:51 GMTContent-Length: 0

浏览器跟踪重定向地址

          现在浏览器知道了 “HTTP://www.facebook.com/”才是要访问的正确地址，所以它会发送另一个http请求。

服务器处理请求

            服务器接收到获取请求，然后处理并返回一个响应。这表面上看起来是一个顺向的任务，但其实这中间发生了很多有意思的东西，就像作者博客这样简单的网站，何况像facebook那样访问量大的网站呢！web服务器软件(像IIS和阿帕奇)接收到HTTP请求，然后确定执行某一请求处理来处理它。请求处理就是一个能够读懂请求并且能生成HTML来进行响应的程序(像ASP.NET,PHP,RUBY…)。 

                                待续！！！！！

服务器发回一个HTML响应                                        待续！！！！！

释放TCP连接      若connection 模式为close，则服务器主动关闭TCP 连接，客户端被动关闭连接，释放TCP 连接;若connection 模式为keepalive，则该连接会保持一段时间，在该时间内可以继续接收请求;

四次挥手

(1)第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。(2)第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1(与SYN相同，一个FIN占用一个序号)，Server进入CLOSE_WAIT状态。(3)第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。(4)第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。为什么建立连接是三次握手，而关闭连接却是四次挥手呢？这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？原因有二：一、保证TCP协议的全双工连接能够可靠关闭二、保证这次连接的重复数据段从网络中消失先说第一点，如果Client直接CLOSED了，那么由于IP协议的不可靠性或者是其它网络原因，导致Server没有收到Client最后回复的ACK。那么Server就会在超时之后继续发送FIN，此时由于Client已经CLOSED了，就找不到与重发的FIN对应的连接，最后Server就会收到RST而不是ACK，Server就会以为是连接错误把问题报告给高层。这样的情况虽然不会造成数据丢失，但是却导致TCP协议不符合可靠连接的要求。所以，Client不是直接进入CLOSED，而是要保持TIME_WAIT，当再次收到FIN的时候，能够保证对方收到ACK，最后正确的关闭连接。再说第二点，如果Client直接CLOSED，然后又再向Server发起一个新连接，我们不能保证这个新连接与刚关闭的连接的端口号是不同的。也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题，但是还是有特殊情况出现：假设新连接和已经关闭的老连接端口号是一样的，如果前一次连接的某些数据仍然滞留在网络中，这些延迟数据在建立新连接之后才到达Server，由于新连接和老连接的端口号是一样的，又因为TCP协议判断不同连接的依据是socket pair，于是，TCP协议就认为那个延迟的数据是属于新连接的，这样就和真正的新连接的数据包发生混淆了。所以TCP连接还要在TIME_WAIT状态等待2倍MSL，这样可以保证本次连接的所有数据都从网络中消失。       

客户端浏览器解析HTML内容       客户端将服务器响应的 html 文本解析并显示                                         待续！！     

浏览器获取嵌入在HTML中的对象

       在浏览器显示HTML时，它会注意到需要获取其他地址内容的标签。这时浏览器会发送一个获取请求来重新获得这些文件。这些地址都要经历一个和HTML读取类似的过程。所以浏览器会在DNS中查找这些域名，发送请求，重定向等等…

                                     待续！！！

- END -

长风破浪会有时，直挂云帆济沧海！