HTTP协议详解以及URL具体访问过程 ,状态码


HTTP协议详解以及URL具体访问过程

  1、简介
  • 2、URI与URL
  • 3、TCP握手连接以及断开(扩展)
  • 4、特点
  • 5、HTTP请求
  •   5.1、Request 消息的结构
  •   5.2、请求方法
  •   5.3、http的无状态以及建立连接方式
  •   5.4、请求行
  •   5.5、请求头
  •   5.6、请求主体
  • 6、HTTP响应
  •   6.1、Response 消息的结构
  •   6.2、响应行
  •   6.3、响应头
  •   6.4、响应主体
  • 7、HTTP请求详细过程
  •   7.1、 输入地址
  •   7.2、浏览器查找域名的IP
  •   7.3、浏览器携带IP地址向Web服务器发起HTTP请求
  •   7.4、服务器的永久重定向响应 
  •   7.5、发出新的请求(重定向)
  •   7.6、服务器主机处理
  •   7.7、Web应用服务器处理http请求
  •   7.8、浏览器处理并显示html文件
  • 8、总结
  • 9、参考文献
  • 回到顶部回到顶部回到顶部oneSong所画的一张金典TCP通讯图片

      上图中主要分为三部分:建立连接、传输数据、断开连接。

      建立连接:

      三次握手即可建立TCP连接

      1、第一次握手:客户端发送syn包(seq=x)到服务器,并进入SYN_SEND状态,等待服务器确认;

      2、第二次握手:服务器收到syn包,必须确认客户的SYN(ack=x+1),同时自己也发送一个SYN包(seq=y),即SYN+ACK包,此时服务器进入SYN_RECV状态;

      3、第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=y+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手。

      握手过程中传送的包里不包含数据,三次握手完毕后,客户端与服务器才正式开始传送数据。理想状态下,TCP连接一旦建立,在通信双方中的任何一方主动关闭连接之前,TCP 连接都将被一直保持下去。

      为什么需要三次握手呢?

      相互确认!(网上有很多解释,这里就不多讲了)

      数据传输:

      建立好连接后,开始传输数据。TCP数据传输牵涉到的概念很多:超时重传、快速重传、流量控制、拥塞控制等等。(这一切都是为了提供可靠的字节流服务)

      断开连接:

      四次握手即可断开TCP连接

      1、第一次握手:主动关闭方发送一个FIN,用来关闭主动方到被动关闭方的数据传送,也就是主动关闭方告诉被动关闭方:我已经不会再给你发数据了(当然,在fin包之前发送出去的数据,如果没有收到对应的ack确认报文,主动关闭方依然会重发这些数据),但此时主动关闭方还可以接受数据。

      2、第二次握手:被动关闭方收到FIN包后,发送一个ACK给对方,确认序号为收到序号+1(与SYN相同,一个FIN占用一个序号)。

      3、第三次握手:被动关闭方发送一个FIN,用来关闭被动关闭方到主动关闭方的数据传送,也就是告诉主动关闭方,我的数据也发送完了,不会再给你发数据了。

      4、第四次握手:主动关闭方收到FIN后,发送一个ACK给被动关闭方,确认序号为收到序号+1,至此,完成四次挥手。

      白话文:

      1、第一次握手,浏览器对服务器说:“煞笔,我不再给你发数据啦,但可以接受数据。”

      2、第二次握手,服务器对浏览器说:“骚货,我知道啦!”

      3、第三次握手,服务器对浏览器说:“骚货,我也不再给你发数据啦!”

      4、第四次握手,浏览器对服务器说:“煞笔,我知道啦!”

    回到顶部回到顶部回到顶部回到顶部回到顶部回到顶部回到顶部回到顶部回到顶部回到顶部回到顶部回到顶部回到顶部回到顶部咸鱼老弟的博客文章

    回到顶部回到顶部回到顶部回到顶部回到顶部回到顶部回到顶部wKiom1LSX3KATYWYAAAx2GkMEO4103.jpg

    假设

    /           在数据区占据 1、2号block ,/其实也是一个目录 里面有3个目录  web 111

    web         占据 5号block  是目录 里面有2个目录 echo data

    echo        占据 11号 block  是目录  里面有1个文件 index.php

    index.php   占据 15 16号 block  是文件

    其在文件系统中分布如下图所示:

    那么内核究竟是怎么找到index.php这个文件的呢?

      内核拿到nginx的IO系统调用要获取/web/echo/index.php这个文件请求之后

      ① 内核读取元数据区 / 的inode,从inode里面读取/所对应的数据块的编号,然后在数据区找到其对应的块(1 2号块),读取1号块上的映射表找到web这个名称在元数据区对应的inode号

      ② 内核读取web对应的inode(3号),从中得知web在数据区对应的块是5号块,于是到数据区找到5号块,从中读取映射表,知道echo对应的inode是5号,于是到元数据区找到5号inode

      ③ 内核读取5号inode,得到echo在数据区对应的是11号块,于是到数据区读取11号块得到映射表,得到index.php对应的inode是9号

      ④ 内核到元数据区读取9号inode,得到index.php对应的是15和16号数据块,于是就到数据区域找到15 16号块,读取其中的内容,得到index.php的完整内容

    回到顶部回到顶部回到顶部图解TCP-IP协议》 

    2. 《一次完整的HTTP事务是怎样一个过程?》

    3. 《【原】老生常谈-从输入url到页面展示到底发生了什么》

    4. 《浅析HTTP协议》

    5. 《HTTP协议详解》

     

    (以上是自己的一些见解,若有不足或者错误的地方请各位指出)

     作者:那一叶随风   http://www.cnblogs.com/phpstudy2015-6/

     原文地址:http://www.cnblogs.com/phpstudy2015-6/p/6810130.html 

     声明:只代表本人在工作学习中某一时间内总结的观点或结论。转载时请在文章页面明显位置给出原文链接

     

    1|0  http状态码基本上可以分为5类:

    1|1  1xx为消息类,该类状态码用于表示服务器临时回应。

        100 continue 表示出的请求已经被服务器接收,游览器应当继续发送请求的其余部分(HTTP1.1)

        101 switching pototcols 服务器将遵从客户的请求转换到另外一种协议(HTTP1.1)。

    1|2  2xx 表示浏览器端请求被处理成功

        200 ok 一切正常

        201 created 服务器已经创建了文档,location 头给出了他的URL。

        202 accepted 已经接收请求,但是尚未处理完成。

        203 non-authoritative information 文档已经正常的返回,但一些应答头可能不正确,因为使用的是的文档的拷贝(HTTP 1.1新)。

        204 no content 没有新文档,游览器应该继续显示原来的文档,这个跟下面的304非常相似。

        205 Reset content 没有新的内容,到那时游览器应该重置它所显示的内容,用来强制清楚表单输入内容(HTTP1.1 新)

        206 partial content 客户发送了一个带有range头的GET请求,服务器完成了它(HTTP1.1  新)。注意 通过Range 可以实现断点续传。

    1|3  3xx 重定向。

        300 Multiple choices 客户请求的文档可以在多个位置找到,这些位置已经在返回的文档内列出,如果服务器要提出优先选择,则应该在location 应答头指明。

        301 Mulitiple permanently 客户请求的文档在其他地方,新的url在location 头中给出,浏览器应该自动的访问新的URL。

        302 Found 类似301,但新的URL应该被视为临时性的替代,而不是永久性的,注意,在HTTP1.0中对应的状态信息moved Temporatily。出现该状态码,浏览器能够给自动访问新的URL,因此他是一个很有用的状态代码。

        注意这个状态代码有时候可以和301替换使用,例如,如果浏览器错误的请求http:// host/~user(缺少了后面的斜杠,有的服务器返回301,有的返回302)。严格的说,我们只能假定原来的请求是GET时浏览器才会自动重定向。

        303 see other 类似于301/302,不同之处在于,如果原来的请求是post,location头指定的重定向目标文档应该通过get提取(http 1.1 新)。

        304 not modified 客户端有缓冲的文档并发出了一个条件性的请求(一般是提供if -modified -since 头表示客户端执行比指定日期更新的文档)。服务器告诉客户,原来缓冲的文档还可以继续使用。

        305 use proxy 客户请求的文档应该通过location 头所指明的代理服务器提取(HTTP 1.1新)。

        307 temporary redirect 和302(found)相同,许多浏览器会错误的相应302应该进行重定向,即使原来的请求是post,即使它实际上只在post请求的应答是303时,才能重定向。由于这个原因,HTTP1.1新增了307,以便更加清楚的区分几个状态代码,当出现303应答时,浏览器可以跟随重定向的get和post请求,如是307应答,则浏览器只能跟随对get的请求的重定向。

    1|4  400 错误

        400 Bad Request 请求出现语法错误。

        401 unauthorized 客户试图未经授权访问受密码保护的页面。应答中会包含-WWW-Authenticate头,浏览器据此显示用户名字和密码对话框,然后再填写合适的authorization头后再次发送请求。

        403 Forbidden 资源不可用。服务器理解客户的需求,但是拒绝处理他通常由于服务器上文件或目录的权限设置问题。

        404 NO Found 无法找到指定位置的资源,也是一个常用的应答。

        405 Method not allowed 请求方法(GET、POST、HEAD、Delete、put、trace等)对指定的资源不适用。(HTTP 1.1新)

        406 not acceptable 指定的资源已经找到,但是mime类型和客户在accpet头中所指定的不兼容(HTTP 1.1新)

        407 proxy authentication  reqired 类似于401 ,表示客户必须先经过代理服务器的授权。(HTTP 1.1新)

        408 request timeout 在服务器许可的等待时间内,客户一直没有发出任何请求。客户可以在以后重复同一请求。(HTTP 1.1新)

        409 conflict 通常和put 请求有关,由于请求和资源的当前状态相冲突,因此请求不能成功(HTTP 1.1新)

        410 Gone 所请求的文档已经不在可用,而且服务器不知道应该重新到哪一个地址,他和404的不同在于,返回407表示文档永久的离开了指定的位置,而404表示由于位置的原因文档不可用。(HTTP 1.1新)

        411 length required 服务器不能处理请求,除非客户发送一个contene-length头(HTTP 1.1新)

        412 preconfition Failed请求头中指定的一些前提条件失败(HTTP 1.1新)

        413 request entity too large 目标文档的大小超过服务器当前原意处理的大小。如果服务器认为自己能够稍后再处理请求,则应该提供一个retry-After头(HTTP 1.1新)

        414 Request URL Too loog URL太长( HTTP 1.1新)

        416 required range not satisfiable 服务器不能满足客户在请求中的指定range 头(HTTP 1.1新)

    1|5  5xx服务器错误

        500 internal Server Error 服务器遇到了意料不到的情况,不能完成客户的请求

        501 Not lmplemented 服务器不支持请求所需要的功能。例如,客户发出来了一个服务器不支持的put请求。

        502Bad Gateway 服务器作为网关或者代理时,为了完成请求访问下一个服务器,但该服务器返回了非法的应答。

        503 service unavilable 服务器由于维护或者负载过重未能应答。例如,servlet 可能在数据库连接池已满的情况下返回503.服务器返回503时可以提供一个retry-after头。

        504 gateway timeout 作为代理或网关服务器使用,表示不能及时的从远程服务器获得应答(HTTP 1.1新)

        505 HTTPversion not supported 服务器不支持请求中所指明的HTTP版本。(HTTP 1.1新)