精华内容
下载资源
问答
  • 一次完整的HTTP请求过程(深入分析)
    千次阅读 多人点赞
    2019-08-22 11:09:58

    前一段时间,面试问到了这个问题,感觉自己回答的不是很好,
    当时我的回答是

    1.域名解析(这个说了一下域名解析的过程)  ,解析出对应IP地址
    2.解析成功之后,发起TCP三次握手建立连接
    3.建立连接后发起HTTPS请求
    4.服务器响应https请求,浏览器得到html代码
    5.浏览器解析html代码,并请求静态资源(html/css/js等)
    6.然后浏览器渲染,展示给用户

    但是当时面试官问我, 发起http请求到服务器然后返回给客户端主要做了那些工作,但是我一下蒙了就没有想起来,当时回答这一块就感觉很一般。今天来总结一下一次完整的HTTP请求过程到底经历了什么

     我们按照上面的步骤一步一步详细说明

    1.域名解析

    域名解析这一步,我当时回答的比较完整,因为之前自己在阿里云上注册了一个域名,然后详细看了一下域名解析的步骤,《深入分析java web》许令波著,当中有详细将,下图借鉴《深入分析java web》当中DNS解析所用到的图

     

    1)首先会搜索浏览器自身的DNS缓存(缓存时间比较短,大概只有1分钟,且只能容纳1000条缓存)

    2)如果浏览器自身的缓存里面没有找到,那么浏览器会搜索操作系统自身的DNS缓存,其实操作系统也会有一个域名解析的过程,在Windows中可以通过C:\Windows\System32drivers\etc\hosts文件来设置,你可以将任何域名解析到任何能够访问的IP地址。如果你在这里指定了一个域名对应的IP地址,那么浏览器会首先使用这个IP地址。  在Linux中这个配置文件是/etc/hosts,修改这个文件可以达到同样的目的。操作系统会在缓存中缓存这个解析结果,缓存的时间同样是受这个域名的失效时间和缓存的空间大小控制的。

    小总结:   前面这两个步骤都是在本机完成的,所以在图1-10中没有表示出来。到这里还没有涉及真正的域名解析服务器,如果在本机中仍然无法完成域名的解析,就会真正请求域名服务器来解析这个域名了。

    3)在我们的网络配置中都会有“DNS服务器地址”这一项,这个地址就用于解决前面所说的如果两个过程无法解析时要怎么办,操作系统会把这个域名发送给这里设置的LDNS(Local DNS),也就是本地区的域名服务器。(这个DNS通常都提供给你本地互联网接入的一个DNS解析服务,例如你是在学校接入互联网,那么你的DNS服务器肯定在你的学校,如果你是在一个小区接入互联网的,那这个DNS就是提供给你接入互联网的应用提供商,即电信或者联通,也就是通常所说的SPA)

    小总结:这个专门的域名解析服务器性能都会很好,它们一般都会缓存域名解析结果,当然缓存时间是受域名的失效时间控制的,一般缓存空间不是影响域名失效的主要因素。大约80%的域名解析都到这里就已经完成了,所以LDNS主要承担了域名的解析工作。


    4)如果LDNS仍然没有命中,就直接到RootServer域名服务器请求解析。


    5)根域名服务器返回给本地域名服务器一个所 查询域的主域名服务器(gTLdServer)地址。gTLD是国际顶级域名服务器,如.com、 .cn、.org 等,全球只有(台左右。


    6)本地域名服务器(Local DNS Server) 再向上-步返回的gTLD服务器发送请求。


    7)接受请求的gTLD服务器查找并返回此域名对应的Name Server域名服务器的地址,这个Name Server通常就是你注册的域名服务器,例如你在某个域名服务提供商申请的域名,那么这个域名解析任务就由这个域名提供商的服务器来完成。


    8)NameServer域名服务器会查询存储的域名和IP的映射关系表,在正常情况下都根据域名得到目标IP记录,连同一个TTl值返回给DNS Server域名服务器。


    9)返回该域名对应的IP和TTL值,Local DNS Server 会缓存这个域名和IP的对应关系,缓存的时间由TTL值控制。


    10)把解析的结果返回给用户,用户根据TTL值缓存在本地系统缓存中,城解析过程结束。


    在实际的DNS解析过程中,可能还不止这10个步骤,如Name Sever也可能有多或者有一个GTM来负载均衡控制,这都有可能会影响域名解析的过程。


    总结: 一般情况前5步是可以解析出域名的。

     2.TCP建立连接(三次握手)

    ACK TCP报头的控制位之一,対数据迸行确认.硝人由目的端发出,用它来告泝发送端这个序列号之前的数据段都收到了。

    比如,确认号为x,則表示前x-1个数据段都收到了,只有当ACK=1肘,确认号オ有效当,ACK=0时,确认号无效,这时会要求重传数据,保正数据的完整性.SYN同歩序列号,TCP建立连接吋将这个位置1

    FIN发送端完成发送任努位,当TCP完成数据传输需要断开吋,提出断开连接的一方将这位置1
     

    3.建立TCP连接之后,发起HTTP请求

     HTTP请求报文由三部分组成:请求行请求头请求正文

      1.请求行:用于描述客户端的请求方式,请求的资源名称以及使用的HTTP协议的版本号(例:GET/books/java.html HTTP/1.1)

      2.请求头:用于描述客户端请求哪台主机,以及客户端的一些环境信息等

      注:这里提一个请求头 Connection,Connection设置为 keep-alive用于说明 客户端这边设置的是,本次HTTP请求之后并不需要关闭TCP连接,这样可以使下次HTTP请求使用相同的TCP通道,节省TCP建立连接的时间

      3.请求正文:当使用POST, PUT等方法时,通常需要客户端向服务器传递数据。这些数据就储存在请求正文中(GET方式是保存在url地址后面,不会放到这里)

    4.服务器端响应http请求,浏览器得到html代码

    HTTP响应也由三部分组成:状态码,响应头和实体内容

      1.状态码:状态码用于表示服务器对请求的处理结果

      2.响应头:响应头用于描述服务器的基本信息,以及客户端如何处理数据

      3.实体内容:服务器返回给客户端的数据

     5.浏览器解析html代码,并请求html代码中的资源

    浏览器拿到html文件后,就开始解析其中的html代码,遇到js/css/image等静态资源时,就向服务器端去请求下载(会使用多线程下载,每个浏览器的线程数不一样),这是时候就用上 keep-alive特性了,建立一次HTTP连接,可以请求多个资源,下载资源的顺序就是按照代码里面的顺序,但是由于每个资源大小不一样,而浏览器又是多线程请求请求资源,所以这里显示的顺序并不一定是代码里面的顺序。

    6.浏览器对页面进行渲染呈现给用户

    最后,浏览器利用自己内部的工作机制,把请求的静态资源和html代码进行渲染,渲染之后呈现给用户

       浏览器是一个边解析边渲染的过程。首先浏览器解析HTML文件构建DOM树,然后解析CSS文件构建渲染树,等到渲染树构建完成后,浏览器开始布局渲染树并将其绘制到屏幕上。这个过程比较复杂,涉及到两个概念: reflow(回流)和repain(重绘)。DOM节点中的各个元素都是以盒模型的形式存在,这些都需要浏览器去计算其位置和大小等,这个过程称为relow;当盒模型的位置,大小以及其他属性,如颜色,字体,等确定下来之后,浏览器便开始绘制内容,这个过程称为repain。页面在首次加载时必然会经历reflow和repain。reflow和repain过程是非常消耗性能的,尤其是在移动设备上,它会破坏用户体验,有时会造成页面卡顿。所以我们应该尽可能少的减少reflow和repain。

      JS的解析是由浏览器中的JS解析引擎完成的。JS是单线程运行,JS有可能修改DOM结构,意味着JS执行完成前,后续所有资源的下载是没有必要的,所以JS是单线程,会阻塞后续资源下载

     

    总结:

    1.域名解析(这个说了一下域名解析的过程)  ,解析出对应IP地址
    2.解析成功之后,发起TCP三次握手建立连接
    3.建立连接后发起HTTPS请求
    4.服务器响应https请求,浏览器得到html代码
    5.浏览器解析html代码,并请求静态资源(html/css/js等)
    6.然后浏览器渲染,展示给用户

     

    参考:

    1. https://www.cnblogs.com/xuzekun/p/7527736.html

    2.《深入分析java web》许令波著

     

    更多相关内容
  • Tomcat处理HTTP请求过程分析

    千次阅读 2018-12-14 14:43:02
    Tomcat处理HTTP请求过程分析 一、Tomcat是什么? Tomcat是一个web应用服务器,是一个Servlet/Jsp容器,主要负责将客户端请求传递给对应的Servlet,并且将Servlet的响应数据返回给客户端。 Tomcat是基于组件的...

    Tomcat处理HTTP请求过程分析

    一、Tomcat是什么?

    Tomcat是一个web应用服务器,是一个Servlet/Jsp容器,主要负责将客户端请求传递给对应的Servlet,并且将Servlet的响应数据返回给客户端。

    Tomcat是基于组件的服务器。

    二、Tomcat体系结构

    Tomcat是一个基于组件的服务器,它的构成组件都是可配置的。其各个组件都在Tomcat安装目录下的../conf/server.xml文件中配置

    server.xml文件源代码如下

    <?xml version="1.0" encoding="UTF-8"?>
    
    <!--顶层类元素,可以包含多个Service-->
    
    <Server port="8005" shutdown="SHUTDOWN">  
    
      <Listener className="org.apache.catalina.startup.VersionLoggerListener" />
    
      <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
    
      <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
    
      <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
    
      <Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
    
      <GlobalNamingResources>
    
        <Resource name="UserDatabase" auth="Container"
    
                  type="org.apache.catalina.UserDatabase"
    
                  description="User database that can be updated and saved"
    
                  factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
    
                  pathname="conf/tomcat-users.xml" />
    
      </GlobalNamingResources>
    
      <!--顶层类元素,可包含一个Engine(container),多个connector-->
    
      <Service name="Catalina">
    
      <!--连接器类元素,代表通信接口-->
    
        <Connector port="8080" protocol="HTTP/1.1"
    
                   connectionTimeout="20000"
    
                   redirectPort="8443" />
    
        <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
    
        <!--容器类元素,为特定的service组件处理客户请求-->
    
        <Engine name="Catalina" defaultHost="localhost">
    
            <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
    
                   resourceName="UserDatabase"/>
    
            </Realm>
    
            <!--容器类元素,为特定的虚拟主机组件处理客户请求-->
    
          <Host name="localhost"  appBase="webapps"
    
                unpackWARs="true" autoDeploy="true">
    
            <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
    
                   prefix="localhost_access_log" suffix=".txt"
    
                   pattern="%h %l %u %t "%r" %s %b" />
    
          </Host>
    
        </Engine>
    
      </Service>
    
    </Server>

     

    由上图可以看出Tomcat的心脏是两个核心组件:Connector(连接器)和Container(容器)。其中一个Container可以选择多个Connector

    扩展:Tomcat默认提供两个Connector连接器,一个默认监听8080端口,一个默认监听8009端口,这两种连接器有什么区别呢?redirectPort有什么作用?

    (1)8080端口监听的是通过HTTP/1.1协议访问的连接,而8009端口主要负责和其他HTTP服务器(如Apache、IIS)建立连接,使用AJP/1.3协议,当Tomcat和其他服务器集成时就会使用到这个连接器。如下图。

    Web1和Web2都是访问服务器的index.jsp页面。Web1直接访问Tomcat服务器,访问地址是http://localhost:8080/index.jsp。Web2访问HTTP服务器,HTTP服务器再通过访问Tomcat的8009端口找到index.jsp。假设HTTP服务器的端口为80端口,则访问地址为http://localhost:80/index.jsp 或者 http://localhost/index.jsp。

    Apache、IIS服务器一般只支持静态页面,如HTML,不支持JSP动态页面。Tomcat对HTML的解析速度不如Apache、IIS服务器。因此一般将两者整合使用。

    (2)redirectPort字面意思是重定向端口。当用户用http请求某个资源,而该资源本身又被设置了必须要https方式访问,此时Tomcat会自动重定向到这个redirectPort设置的https端口。

     

    三、组件

    1、Connector组件

    Connector 最重要的功能就是接收连接请求然后分配线程让 Container来处理这个请求,所以这必然是多线程的,多线程的处理是 Connector 设计的核心。Connector监听指定端口上请求,当请求到来时创建一个request和response对象交换数据,然后新建一个线程来处理请求并把request和response传递给Engine组件,最后从Engine获取一个响应并返回给客户端。

    Connector组件常用属性说明:

    (1) address:指定连接器监听的地址,默认为所有地址,即0.0.0.0可以自己指定地。(2) maxThreads:支持的最大并发连接数,默认为200;

    (3) port:监听的端口;

    (4) protocol:连接器使用的协议,默认为HTTP/1.1,定义AJP协议时通常为AJP/1.3;

    (5) redirectPort:如果某连接器支持的协议是HTTP,当接收客户端发来的HTTPS请求时,则转发至此属性定义的端口;

    (6) connectionTimeout:等待客户端发送请求的超时时间,单位为毫秒,默认为60000,即1分钟;

    (7) enableLookups:是否通过request.getRemoteHost()进行DNS查询以获取客户端的主机名;默认为true; 进行反解的,可以设置为false

    (8) acceptCount:设置等待队列的最大长度;通常在tomcat所有处理线程均处于繁忙状态时,新发来的请求将被放置于等待队列中;

     

     

    1. container组件

    Container是容器的父接口,该容器的设计用的是典型的责任链的设计模式,它由四个自容器组件构成,分别是Engine、Host、Context、Wrapper。这四个组件是负责关系,存在包含关系。通常一个Servlet class对应一个Wrapper,如果有多个Servlet则定义多个Wrapper,如果有多个Wrapper就要定义一个更高的Container,如Context。 Context定义在父容器 Host 中,其中Host 不是必须的,但是要运行 war 程序,就必须要 Host,因为 war 中必有 web.xml 文件,这个文件的解析就需要 Host 了,如果要有多个 Host 就要定义一个 top 容器 Engine 了。而 Engine 没有父容器了,一个 Engine 代表一个完整的 Servlet 引擎。

    2.1、Engine

    Engine是Servlet处理器的一个实例,即servlet引擎,默认为定义在server.xml中的Catalina。Engine需要defaultHost属性来为其定义一个接收所有请求的虚拟主机host组件

    2.2、Host

    Host是Engine的子容器。一个 Host 在 Engine 中代表一个虚拟主机,这个虚拟主机的作用就是运行多个应用、接收并处理请求、保存一个主机应该有的信息。

    常用属性说明:

    (1)appBase:此Host的webapps目录,项目存放路径,可以使用绝对路径

    (2)autoDeploy:在Tomcat处于运行状态时放置于appBase目录中的应用程序文件是否自动进行deploy;默认为true;

    (3)unpackWars:在启用此webapps时是否对WAR格式的归档文件先进行展开;默认为true;

    2.3、Context

    Context 代表 Servlet 的 Context,它具备了 Servlet 运行的基本环境,理论上只要有 Context 就能运行 Servlet 了。简单的 Tomcat 可以没有 Engine 和 Host。Context 最重要的功能就是管理它里面的 Servlet 实例,Servlet 实例在 Context 中是以 Wrapper 出现的,还有一点就是 Context 如何才能找到正确的 Servlet 来执行它呢? Tomcat5 以前是通过一个 Mapper 类来管理的,Tomcat5 以后这个功能被移到了 request 中,在前面的时序图中就可以发现获取子容器都是通过 request 来分配的

    常用属性定义:

    (1) docBase:相应的Web应用程序的存放位置;也可以使用相对路径,起始路径为此Context所属Host中appBase定义的路径;切记,docBase的路径名不能与相应的Host中appBase中定义的路径名有包含关系,比如,如果appBase为deploy,而docBase绝不能为deploy-bbs类的名字;

    (2)path:相对于Web服务器根路径而言的URI;如果为空“”,则表示为此webapp的根路径;如果context定义在一个单独的xml文件中,此属性不需要定义,有可能是别名;

    (3) reloadable:是否允许重新加载此context相关的Web应用程序的类;默认为false;

    2.4、Wrapper

    Wrapper 代表一个 Servlet,它负责管理一个 Servlet,包括Servlet 的装载、初始化、执行以及资源回收。Wrapper 是最底层的容器,它没有子容器了,所以调用它的 addChild 将会报错。 Wrapper 的实现类是 StandardWrapper,StandardWrapper 还实现了 ServletConfig,由此看出 StandardWrapper 将直接和 Servlet 的各种信息打交道。

    2.5、Realm

    Wrapper 代表一个 Servlet,它负责管理一个 Servlet,包括的 Servlet 的装载、初始化、执行以及资源回收。Wrapper 是最底层的容器,它没有子容器了,所以调用它的 addChild 将会报错。 Wrapper 的实现类是 StandardWrapper,StandardWrapper 还实现了拥有一个 Servlet 初始化信息的 ServletConfig,由此看出 StandardWrapper 将直接和 Servlet 的各种信息打交道。

    2.6、Value

    Valve类似于过滤器,它可以工作于Engine和Host/Context之间、Host和Context之间以及Context和Web应用程序的某资源之间。一个容器内可以建立多个Valve,而且Valve定义的次序也决定了它们生效的次序。

    四、Tomcat处理一个HTTP请求的过程

     

    1.用户在浏览器中输入网址localhost:8080/test/index.jsp,请求被发送到本机端口8080,被在那里监听的Coyote HTTP/1.1 Connector获得;

    2.Connector把该请求交给它所在的Service的Engine(Container)来处理,并等待Engine的回应;

    3.Engine获得请求localhost/test/index.jsp,匹配所有的虚拟主机Host;

    4.Engine匹配到名为localhost的Host(即使匹配不到也把请求交给该Host处理,因为该Host被定义为该Engine的默认主机)名为localhost的Host获得请求/test/index.jsp,匹配它所拥有的所有Context。Host匹配到路径为/test的Context(如果匹配不到就把该请求交给路径名为 的Context去处理);

    5.path=/test的Context获得请求/index.jsp,在它的mapping table中寻找出对应的Servlet。Context匹配到URL Pattern为*.jsp的Servlet,对应于JspServlet类;

    6.构造HttpServletRequest对象和HttpServletResponse对象,作为参数调用JspServlet的doGet()或doPost(),执行业务逻辑、数据存储等;

    7.Context把执行完之后的HttpServletResponse对象返回给Host;

    8.Host把HttpServletResponse对象返回给Engine;

    9.Engine把HttpServletResponse对象返回Connector;

    10.Connector把HttpServletResponse对象返回给客户Browser。

     

    参考:https://www.cnblogs.com/small-boy/p/8042860.html

     

    展开全文
  • 一次完整的http请求过程是怎样的?

    千次阅读 多人点赞 2021-06-08 23:02:51
    我们打开浏览器,在地址栏输入\...如果URL通过验证,那么可以解析得到协议(http或者https)、域名(wukong)、资源(首页)等信息。 DNS查询 浏览器会先检查域名信息是否在缓存中。 再检查域名是否在..

    我们打开浏览器,在地址栏输入\www.wukong.com\,几秒后浏览器打开悟空问答的页面,那么这几秒钟内发生了哪些事情,我就带大家一起看看完整的流程:

    解析URL

    浏览器首先会对输入的URL进行验证,如果不合法的时候,那么会把输入的文字传给默认的搜索引擎,比如你只在地址栏输入“悟空问答”几个字。

    如果URL通过验证,那么可以解析得到协议(http或者https)、域名(wukong)、资源(首页)等信息。

    DNS查询

    • 浏览器会先检查域名信息是否在缓存中。

    • 再检查域名是否在本地的Hosts文件中。

    • 如果还不在,那么浏览器会向DNS服务器发送一个查询请求,获得目标服务器的IP地址。

    TCP封包及传输

    这时候浏览器获得了目标服务器的IP(DNS返回)、端口(URL中包含,没有就使用默认),浏览器会调用库函数socket,生成一个TCP流套接字,也就是完成了TCP的封包。

    TCP封包完成之后,就可以传输了,在完成“你瞅啥”,“瞅你咋地”,“来,过来唠唠”一系列操作之后,浏览器和服务器就完成了TCP的三次握手,建立了连接,后面就可以请求服务器资源了。

    服务器接收请求并相应

    • HTTP有很多请求方法,比如:GET/POST/PUT/DELETE等等,我们浏览器输入URL这种,是GET方法。

    • 服务器接收到GET请求,服务器根据请求信息,获得相应的相应内容。例如我们输入的是:\www.wukong.com\,那么意味着访问首页文件。

    浏览器解析并渲染

    浏览器从服务器拿到了想要访问的资源,大多数时候,这个资源就是HTML页面,当然也可能是一个其他类型的文件。

    • 浏览器先对HTML文档进行解析,生成解析树(以DOM元素为节点的树)。

    • 加载页面的外部资源,比如JS、CSS、图片。

    • 遍历DOM树,并计算每个节点的样式,最终完成渲染,变成我们看到的页面。

    这次请求响应之后,会断开连接,就这样,完成了一次HTTP的请求。

     

     

     

     

    Http请求的一次详解:

    1. 客户端输入URL

    2. 客户端检测缓存:

    有缓存且较新,客户端直接读取本地缓存进行资源展示;

    有缓存但是不新,准备http请求包,发送至服务端进行缓存校验;

    备注:http1.0中Expire、http1.1中是Cache-Control根据发起http请求:

    请求报文包含:
    a) 请求行用来说明请求类型(get\post\delete等)、要访问的资源(URI)以及使用的HTTP版本(1.0还是1.1)b) 首部(header)HOST将指出请求的目的地;User-Agent由浏览器来定义,自动发送;Connection:通常设置为keep-Alive, 长连接;其他首部包括等。c) 空行d) 请求实体

    3. 提取请求首部HOST通过DNS域名解析获取服务IP(DNS缓存\递归等)

    4. 通过IP与默认端口创建TCP连接,进行http请求报文数据发送,其中重点就三次握手进行描述:

    客户端向服务端发送syn=1,seq=client请求的ID;
    服务端向客户端发送syn=1,seq=服务端请求的ID,ack=客户端请求的ID+1;客户端向服务端发送syn=0,seq=客户端请求的ID+1,ack=服务端请求的ID+1,data\data…

    5. 服务端程序接受请求,定向到请求路径处理请求:

    服务器对请求报文进行解析,并获取请求的资源及请求方法等相关信息,根据方法,资源,首部和可选的主体部分对请求进行处理

    元数据:请求报文首部
    <method> <URL> <VERSION> HEADERS格式name:value <request body> 示例: Host: www.chuyuni.cn 请求的主机名称 Server: Apache/2.4.7

    HTTP常用请求方式:MethodGET、POST、HEAD、PUT、DELETE、TRACE、OPTIONS

    6.访问资源:

    服务器获取请求报文中请求的资源web服务器,即存放了web资源的服务器,负责向请求者提供对方请求的静态资源,或动态运行后生成的资源

    资源放置于本地文件系统特定的路径:DocRoot
    DocRoot → /var/www/html /var/www/html/images/logo.jpg http://www.magedu.com/images/logo.jpg web服务器资源路径映射方式: (a) docroot (b) alias (c) 虚拟主机docroot(d) 用户家目录docroot

    7. 返回处理结果,准备http响应:

    响应报文包含:
    a) 状态行:http版本(1.1或者1.0),状态码200:请求正常处理304:返回上次请求资源未作改动,验证浏览器的缓存机制400:请求参数错误401:客户端无权访问,要去输入用户名\密码之类的授权信息403:禁止访问(读写权限等影响)404:请求的资源不存在500:服务内部错误502:网关错误503:临时过载或者维护,导致服务端无法正常处理请求b) 首部报文支持的语言\编码格式\等,注意If-Modified-Since:只有当所请求的内容在指定的日期之后又经过修改才返回它,否则返回304“Not Modified”应答,用于服务端缓存校验c) 空行d) 响应报文实体

    8. 通过建立的tcp连接来返回相关的http响应报文及http状态信息,然后根据实际情况看是否关闭连接(Connection的keep-alive)

    9. TCP连接关闭经历4次握手

    客户端主动关闭连接放发送FIN进入FIN_WAIT1状态

    服务端发最后的data和ack客户端接收进入CLOSEWAIT状态,客户端进入接受ACK进入FINWAIT2状态

    服务端主动发FIN,客户端接受FIN并发送ack进入TIMEWAIT状态

    服务器端正式关闭连接进入close状态

    10. 客户端拿到http响应的报文信息,经过一系列前端处理过程最终将请求的资源进行展示。

     

     

    展开全文
  • 一个完整的HTTP请求过程详细

    万次阅读 多人点赞 2018-05-29 14:41:54
    一个完整的HTTP请求过程 整个流程 域名解析 —&gt; 与服务器建立连接 —&gt; 发起HTTP请求 —&gt; 服务器响应HTTP请求,浏览器得到html代码 —&gt; 浏览器解析html代码,并请求html代码中的资源...

    一个完整的HTTP请求过程

    整个流程

    域名解析 —> 与服务器建立连接 —> 发起HTTP请求 —> 服务器响应HTTP请求,浏览器得到html代码 —> 浏览器解析html代码,并请求html代码中的资源(如js、css、图片) —> 浏览器对页面进行渲染呈现给用户

    1. 域名解析

    以Chrome浏览器为例:

    ① Chrome浏览器 会首先搜索浏览器自身的DNS缓存(缓存时间比较短,大概只有1分钟,且只能容纳1000条缓存),看自身的缓存中是否有https://www.cnblogs.com 对应的条目,而且没有过期,如果有且没有过期则解析到此结束。

    注:我们怎么查看Chrome自身的缓存?可以使用 chrome://net-internals/#dns 来进行查看

    ② 如果浏览器自身的缓存里面没有找到对应的条目,那么Chrome会搜索操作系统自身的DNS缓存,如果找到且没有过期则停止搜索解析到此结束.

    注:怎么查看操作系统自身的DNS缓存,以Windows系统为例,可以在命令行下使用 ipconfig /displaydns 来进行查看

    ③ 如果在Windows系统的DNS缓存也没有找到,那么尝试读取hosts文件(位于C:\Windows\System32\drivers\etc),看看这里面有没有该域名对应的IP地址,如果有则解析成功。

    ④ 如果在hosts文件中也没有找到对应的条目,浏览器就会发起一个DNS的系统调用,就会向本地配置的首选DNS服务器(一般是电信运营商提供的,也可以使用像Google提供的DNS服务器)发起域名解析请求(通过的是UDP协议向DNS的53端口发起请求,这个请求是递归的请求,也就是运营商的DNS服务器必须得提供给我们该域名的IP地址),运营商的DNS服务器首先查找自身的缓存,找到对应的条目,且没有过期,则解析成功。如果没有找到对应的条目,则有运营商的DNS代我们的浏览器发起迭代DNS解析请求,它首先是会找根域的DNS的IP地址(这个DNS服务器都内置13台根域的DNS的IP地址),找打根域的DNS地址,就会向其发起请求(请问www.cnblogs.com这个域名的IP地址是多少啊?),根域发现这是一个顶级域com域的一个域名,于是就告诉运营商的DNS我不知道这个域名的IP地址,但是我知道com域的IP地址,你去找它去,于是运营商的DNS就得到了com域的IP地址,又向com域的IP地址发起了请求(请问www.cnblogs.com这个域名的IP地址是多少?),com域这台服务器告诉运营商的DNS我不知道www.cnblogs.com这个域名的IP地址,但是我知道cnblogs.com这个域的DNS地址,你去找它去,于是运营商的DNS又向cnblogs.com这个域名的DNS地址(这个一般就是由域名注册商提供的,像万网,新网等)发起请求(请问www.cnblogs.com这个域名的IP地址是多少?),这个时候cnblogs.com域的DNS服务器一查,诶,果真在我这里,于是就把找到的结果发送给运营商的DNS服务器,这个时候运营商的DNS服务器就拿到了www.cnblogs.com这个域名对应的IP地址,并返回给Windows系统内核,内核又把结果返回给浏览器,终于浏览器拿到了www.cnblogs.com 对应的IP地址,该进行一步的动作了。

    注:一般情况下是不会进行以下步骤的

    如果经过以上的4个步骤,还没有解析成功,那么会进行如下步骤(以下是针对Windows操作系统):

    ⑤ 操作系统就会查找NetBIOS name Cache(NetBIOS名称缓存,就存在客户端电脑中的),那这个缓存有什么东西呢?凡是最近一段时间内和我成功通讯的计算机的计算机名和Ip地址,就都会存在这个缓存里面。什么情况下该步能解析成功呢?就是该名称正好是几分钟前和我成功通信过,那么这一步就可以成功解析。

    ⑥ 如果第⑤步也没有成功,那会查询WINS 服务器(是NETBIOS名称和IP地址对应的服务器)

    ⑦ 如果第⑥步也没有查询成功,那么客户端就要进行广播查找

    ⑧ 如果第⑦步也没有成功,那么客户端就读取LMHOSTS文件(和HOSTS文件同一个目录下,写法也一样)

    如果第八步还没有解析成功,那么就宣告这次解析失败,那就无法跟目标计算机进行通信。只要这八步中有一步可以解析成功,那就可以成功和目标计算机进行通信。

    2. 与服务器建立连接

    2.1 TCP连接的建立

    客户端的请求到达服务器,首先就是建立TCP连接

    来源于:https://blog.csdn.net/u012248450/article/details/51036329

    1. Client首先发送一个连接试探,ACK=0 表示确认号无效,SYN = 1 表示这是一个连接请求或连接接受报文,同时表示这个数据报不能携带数据,seq = x 表示Client自己的初始序号(seq = 0 就代表这是第0号包),这时候Client进入syn_sent状态,表示客户端等待服务器的回复

    2. Server监听到连接请求报文后,如同意建立连接,则向Client发送确认。TCP报文首部中的SYN 和 ACK都置1 ,ack = x + 1表示期望收到对方下一个报文段的第一个数据字节序号是x+1,同时表明x为止的所有数据都已正确收到(ack=1其实是ack=0+1,也就是期望客户端的第1个包),seq = y 表示Server 自己的初始序号(seq=0就代表这是服务器这边发出的第0号包)。这时服务器进入syn_rcvd,表示服务器已经收到Client的连接请求,等待client的确认。

    3. Client收到确认后还需再次发送确认,同时携带要发送给Server的数据。ACK 置1 表示确认号ack= y + 1 有效(代表期望收到服务器的第1个包),Client自己的序号seq= x + 1(表示这就是我的第1个包,相对于第0个包来说的),一旦收到Client的确认之后,这个TCP连接就进入Established状态,就可以发起http请求了。

    问题1:TCP 为什么需要3次握手?

    2个计算机通信是靠协议(目前流行的TCP/IP协议)来实现,如果2个计算机使用的协议不一样,那是不能进行通信的,所以这个3次握手就相当于试探一下对方是否遵循TCP/IP协议,协商完成后就可以进行通信了,当然这样理解不是那么准确。

    问题2:为什么HTTP协议要基于TCP来实现?

    目前在Internet中所有的传输都是通过TCP/IP进行的,HTTP协议作为TCP/IP模型中应用层的协议也不例外,TCP是一个端到端的可靠的面向连接的协议,所以HTTP基于传输层TCP协议不用担心数据的传输的各种问题。

    2.2 常见TCP连接限制

    2.2.1 修改用户进程可打开文件数限制

    在Linux平台上,无论编写客户端程序还是服务端程序,在进行高并发TCP连接处理时,最高的并发数量都要受到系统对用户单一进程同时可打开文件数量的限制(这是因为系统为每个TCP连接都要创建一个socket句柄,每个socket句柄同时也是一个文件句柄)。可使用ulimit命令查看系统允许当前用户进程打开的文件数限制,windows上是256,linux是1024,这个博客的服务器是65535

    2.2.2 修改网络内核对TCP连接的有关限制

    在Linux上编写支持高并发TCP连接的客户端通讯处理程序时,有时会发现尽管已经解除了系统对用户同时打开文件数的限制,但仍会出现并发TCP连接数增加到一定数量时,再也无法成功建立新的TCP连接的现象。出现这种现在的原因有多种。
    第一种原因可能是因为Linux网络内核对本地端口号范围有限制。此时,进一步分析为什么无法建立TCP连接,会发现问题出在connect()调用返回失败,查看系统错误提示消息是“Can’t assign requestedaddress”。同时,如果在此时用tcpdump工具监视网络,会发现根本没有TCP连接时客户端发SYN包的网络流量。这些情况说明问题在于本地Linux系统内核中有限制。

    其实,问题的根本原因在于Linux内核的TCP/IP协议实现模块对系统中所有的客户端TCP连接对应的本地端口号的范围进行了限制(例如,内核限制本地端口号的范围为1024~32768之间)。当系统中某一时刻同时存在太多的TCP客户端连接时,由于每个TCP客户端连接都要占用一个唯一的本地端口号(此端口号在系统的本地端口号范围限制中),如果现有的TCP客户端连接已将所有的本地端口号占满,则此时就无法为新的TCP客户端连接分配一个本地端口号了,因此系统会在这种情况下在connect()调用中返回失败,并将错误提示消息设为“Can’t assignrequested address”。

    2.3 TCP四次挥手

    当客户端和服务器通过三次握手建立了TCP连接以后,当数据传送完毕,肯定是要断开TCP连接的啊。那对于TCP的断开连接,这里就有了神秘的“四次分手”。

    来源于:https://blog.csdn.net/LRH0211/article/details/72724361

    第一次分手:主机1(可以使客户端,也可以是服务器端),设置Sequence Number,向主机2发送一个FIN报文段;此时,主机1进入FIN_WAIT_1状态;这表示主机1没有数据要发送给主机2了;

    第二次分手:主机2收到了主机1发送的FIN报文段,向主机1回一个ACK报文段,Acknowledgment Number为Sequence Number加1;主机1进入FIN_WAIT_2状态;主机2告诉主机1,我“同意”你的关闭请求;

    第三次分手:主机2向主机1发送FIN报文段,请求关闭连接,同时主机2进入LAST_ACK状态;

    第四次分手:主机1收到主机2发送的FIN报文段,向主机2发送ACK报文段,然后主机1进入TIME_WAIT状态;主机2收到主机1的ACK报文段以后,就关闭连接;此时,主机1等待2MSL后依然没有收到回复,则证明Server端已正常关闭,那好,主机1也可以关闭连接了。

    问题1:为什么要四次分手?

    TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式,这就意味着,当主机1发出FIN报文段时,只是表示主机1已经没有数据要发送了,主机1告诉主机2,它的数据已经全部发送完毕了;但是,这个时候主机1还是可以接受来自主机2的数据;当主机2返回ACK报文段时,表示它已经知道主机1没有数据发送了,但是主机2还是可以发送数据到主机1的;当主机2也发送了FIN报文段时,这个时候就表示主机2也没有数据要发送了,就会告诉主机1,我也没有数据要发送了,之后彼此就会愉快的中断这次TCP连接。

    3. 发起HTTP请求

    3.1 HTTP协议

    HTTP是一个客户端和服务器端请求和应答的标准(TCP)。客户端是终端用户,服务器端是网站。通过使用Web浏览器、网络爬虫或者其它的工具,客户端发起一个到服务器上指定端口(默认端口为80)的HTTP请求。

    通俗来讲,他就是计算机通过网络进行通信的规则,是一个基于请求与响应,无状态的,应用层的协议,常基于TCP/IP协议传输数据。目前任何终端(手机,笔记本电脑。。)之间进行任何一种通信都必须按照Http协议进行,否则无法连接。

    3.1.1 四个基于
    1. 请求与响应:客户端发送请求,服务器端响应数据
    2. 无状态的:协议对于事务处理没有记忆能力,客户端第一次与服务器建立连接发送请求时需要进行一系列的安全认证匹配等,因此增加页面等待时间,当客户端向服务器端发送请求,服务器端响应完毕后,两者断开连接,也不保存连接状态,一刀两断!恩断义绝!从此路人!下一次客户端向同样的服务器发送请求时,由于他们之前已经遗忘了彼此,所以需要重新建立连接。
    3. 应用层: Http是属于应用层的协议,配合TCP/IP使用。
    4. TCP/IP: Http使用TCP作为它的支撑运输协议。HTTP客户机发起一个与服务器的TCP连接,一旦连接建立,浏览器(客户机)和服务器进程就可以通过套接字接口访问TCP。

    3.2 HTTP请求报文

    一个HTTP请求报文由请求行(request line)、请求头部(header)、空行和请求数据4个部分组成,下图给出了请求报文的一般格式。

    来源于:https://blog.csdn.net/LRH0211/article/details/72724361

    3.2.1 请求行

    请求行分为三个部分:请求方法、请求地址和协议版本

    请求方法

    HTTP/1.1 定义的请求方法有8种:GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS、TRACE。

    最常的两种GET和POST,如果是RESTful接口的话一般会用到GET、POST、DELETE、PUT。

    请求地址

    URL:统一资源定位符,是一种自愿位置的抽象唯一识别方法。

    组成:<协议>://<主机>:<端口>/<路径> 注:端口和路径有时可以省略(HTTP默认端口号是80)

    https://localhost:8080/index.html?key1=value1&keys2=value2

    协议版本

    协议版本的格式为:HTTP/主版本号.次版本号,常用的有HTTP/1.0和HTTP/1.1

    3.2.2 请求头部

    请求头部为请求报文添加了一些附加信息,由“名/值”对组成,每行一对,名和值之间使用冒号分隔。

    常见请求头如下:

    来源于:https://blog.csdn.net/LRH0211/article/details/72724361

    请求头部的最后会有一个空行,表示请求头部结束,接下来为请求数据,这一行非常重要,必不可少。

    3.2.3 请求数据

    可选部分,比如GET请求就没有请求数据。

    下面是一个POST方法的请求报文:

    POST  /index.php HTTP/1.1    请求行 
    Host: localhost 
    User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20100101 Firefox/10.0.2  请求头 
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8 
    Accept-Language: zh-cn,zh;q=0.5 
    Accept-Encoding: gzip, deflate 
    Connection: keep-alive 
    Referer: http://localhost/ 
    Content-Length:25 
    Content-Type:application/x-www-form-urlencoded 
      空行 
    username=aa&password=1234  请求数据
    

    4. 服务器响应HTTP请求,浏览器得到html代码

    4.1 负载均衡

    接收到HTTP请求之后,就轮到负载均衡登场了,它位于网站的最前端,把短时间内较高的访问量分摊到不同机器上处理。负载均衡方案有软件、硬件两种

    4.1.1 负载均衡硬件方案

    F5 BIG-IP是著名的硬件方案,但这里不作讨论

    4.1.2 负载均衡软件方案

    有LVS HAProxy Nginx等,留作以后补充

    在典型的Rails应用部署方案中,Nginx的作用有两个

    1. 处理静态文件请求
    2. 转发请求给后端的Rails应用
      这是一个简单的Nginx配置文件

    来源于:https://blog.csdn.net/u012248450/article/details/51036329

    后端的Rails服务器通过unix socket与Nginx通信,Nginx伺服public文件夹里的静态文件给用户

    待完善…

    4.2 Rails(应用服务器)

    4.3 数据库(数据库服务器)

    4.4 Redis、Memercache(缓存服务器)

    4.5 消息队列

    4.6 搜索

    4.7 HTTP响应报文

    来源于:https://blog.csdn.net/LRH0211/article/details/72724361

    HTTP响应报文主要由状态行、响应头部、空行以及响应数据组成。

    4.7.1 状态行

    由3部分组成,分别为:协议版本,状态码,状态码描述。

    其中协议版本与请求报文一致,状态码描述是对状态码的简单描述,所以这里就只介绍状态码。

    状态码

    状态代码为3位数字。

    • 1xx:指示信息–表示请求已接收,继续处理。
    • 2xx:成功–表示请求已被成功接收、理解、接受。
    • 3xx:重定向–要完成请求必须进行更进一步的操作。
    • 4xx:客户端错误–请求有语法错误或请求无法实现。
    • 5xx:服务器端错误–服务器未能实现合法的请求。

    下面列举几个常见的:

    来源于:https://blog.csdn.net/LRH0211/article/details/72724361

    4.7.2 响应头部

    与请求头部类似,为响应报文添加了一些附加信息

    常见响应头部如下:

    来源于:https://blog.csdn.net/LRH0211/article/details/72724361

    4.7.3 响应数据

    用于存放需要返回给客户端的数据信息。

    下面是一个响应报文的实例:

    HTTP/1.1 200 OK  状态行 
    Date: Sun, 17 Mar 2013 08:12:54 GMT  响应头部 
    Server: Apache/2.2.8 (Win32) PHP/5.2.5 
    X-Powered-By: PHP/5.2.5 
    Set-Cookie: PHPSESSID=c0huq7pdkmm5gg6osoe3mgjmm3; path=/ 
    Expires: Thu, 19 Nov 1981 08:52:00 GMT 
    Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 
    Pragma: no-cache 
    Content-Length: 4393 
    Keep-Alive: timeout=5, max=100 
    Connection: Keep-Alive 
    Content-Type: text/html; charset=utf-8 
      空行 
      响应数据 
    
    HTTP响应示例 
    
    
    Hello HTTP! 
    

    关于请求头部和响应头部的知识点很多,这里只是简单介绍。

    5. 浏览器解析html代码,并请求html代码中的资源

    浏览器拿到index.html文件后,就开始解析其中的html代码,遇到js/css/image等静态资源时,就向服务器端去请求下载(会使用多线程下载,每个浏览器的线程数不一样),这个时候就用上keep-alive特性了,建立一次HTTP连接,可以请求多个资源,下载资源的顺序就是按照代码里的顺序,但是由于每个资源大小不一样,而浏览器又多线程请求请求资源,所以从下图看出,这里显示的顺序并不一定是代码里面的顺序。

    浏览器在请求静态资源时(在未过期的情况下),向服务器端发起一个http请求(询问自从上一次修改时间到现在有没有对资源进行修改),如果服务器端返回304状态码(告诉浏览器服务器端没有修改),那么浏览器会直接读取本地的该资源的缓存文件。

    图

    详细的浏览器工作原理请看:http://kb.cnblogs.com/page/129756/

    6. 浏览器对页面进行渲染呈现给用户

    最后,浏览器利用自己内部的工作机制,把请求到的静态资源和html代码进行渲染,渲染之后呈现给用户。

    参考文献

    一次完整的HTTP请求与响应涉及了哪些知识? https://blog.csdn.net/LRH0211/article/details/72724361

    一次完整的HTTP请求过程 https://www.cnblogs.com/engeng/articles/5959335.html

    后端知识体系–一次完整的HTTP请求 https://blog.csdn.net/u012248450/article/details/51036329

    展开全文
  • 一次完整的HTTP请求过程

    千次阅读 多人点赞 2018-06-22 11:07:22
    一、 HTTP请求和响应步骤图片来自:理解Http请求与响应以上完整表示了HTTP请求和响应的7个步骤,下面从TCP/IP协议模型的角度来理解HTTP请求和响应如何传递的。二、TCP/IP协议TCP/IP协议模型(Transmission Control ...
  • 以下过程仅是个人理解: ...域名解析 --> 发起TCP的3次握手 --> 建立TCP连接后发起http请求 --> 服务器响应http请求,浏览器得到html代码 --> 浏览器解析html代码,并请求html代码中的资源(如js、css、图片等)
  • 一次完整的http请求过程

    千次阅读 2022-04-22 18:13:22
    一个完整的 HTTP 请求需要经历 DNS 查找,TCP 握手,浏览器发出 HTTP 请求,服务器接收请求,服务器处理请求并发回响应,浏览器接收响应等过程: 首先请求dns服务器(会首先在浏览缓存中获取,找不到就会去host...
  • HTTP请求的完全过程

    万次阅读 多人点赞 2019-05-27 11:22:45
    HTTP请求的完全过程 1.1 浏览器根据域名解析IP地址 浏览器根据访问的域名找到其IP地址。DNS查找过程如下: 浏览器缓存:首先搜索浏览器自身的DNS缓存(缓存的时间比较短,大概只有1分钟,且只能容纳1000条缓存)...
  • HTTP请求详细过程

    千次阅读 2022-03-08 17:06:04
    一. 输入地址 当我们开始在浏览器中输入网址的时候,浏览器其实就已经在... 请求一旦发起,浏览器首先要做的事情就是解析这个域名,一般来说,浏览器会首先查看本地硬盘的 hosts 文件,看看其中有没有和这个域名对
  • 浏览器发送http请求过程分析

    千次阅读 2019-05-21 11:14:52
    请求过程整体流程: 1.域名解析--> 2.发起TCP的3次握手--> 3.建立TCP连接后发起http请求--> 4.服务器响应http请求,浏览器得到html代码--> 5.浏览器解析html代码,并请求html代码中的资源(如js、...
  • HTTP请求过程和原理

    千次阅读 2022-03-14 13:48:32
    HTTP请求过程和原理-面试回答
  • http请求的全部过程,http请求过程:一,DNS域名解析系统详解
  • HTTP请求过程

    万次阅读 多人点赞 2018-01-05 15:37:25
    一、简单描述一次Http的请求过程 域名解析 –> 发起TCP的3次握手 –> 建立TCP连接后发起http请求 –> 服务器响应http请求,浏览器得到html代码 –> 浏览器解析html代码,并请求html代码中的资源(如js、css、图片等...
  • HTTP请求过程——Chrome浏览器Network详解 当我们使用Python进行爬虫的时候,其实就是一个模拟的资源访问返回过程,使用第三方库用目的url向所在的服务器发出请求,网站的服务器接收到这个请求后进行处理和分析,...
  • 步骤四、封包并进行三次握手 浏览器将请求信息进行打包,通过TCP的三次握手将数据传递至服务器。 步骤五、服务器解析、处理、返回数据 服务器通过种种层级、方式拿到传递的数据,对数据进行分析、处理,最后返回...
  • 3. http请求过程 我们在浏览器中输入一个 URL,回车之后便会在浏览器中观察到页面内容,实际上这个过程是浏览器向网站所在的服务器发送了一个 Request,即请求,网站服务器接收到这个 Request 之后进行处理和解析...
  • HTTP请求的完整过程

    千次阅读 2020-07-02 18:18:59
    一次HTTP请求的完整过程——协议篇(DNS、TCP、HTTP) HTTP请求的完全过程 一次完整的HTTP请求过程(深入分析)
  • http请求过程分析

    千次阅读 2016-08-29 16:38:30
    http请求过程 此处以访问百度首页为例,当我们在浏览器地址栏中输入http://www.baidu.com并回车后,我们马上能看到百度的首页,虽然这个过程很短,但这背后究竟发生了什么呢? 现简要地理一下这背后的执行流程: 1...
  • b/s模式http请求过程 先建立tcp连接 浏览器数据经采集进行编码,通过指定的http协议提交方法将编码后的数据(浏览器自动将数据转换成http消息)按照http消息的格式通过tcp连接提交到指定的服务器的应用程序上,...
  • Http请求的流程原理以及请求详解

    千次阅读 2019-03-12 16:04:10
    1.Http请求的基本流程 HTTP协议(HyperText Transfer Protocol,超文本传输协议):是一种发布和接收 HTML页面的方法。 HTTPS(Hypertext Transfer Protocol over Secure Socket Layer)简单讲是HTTP的安全版,在...
  • 建立TCP连接后发起http请求 服务器响应htp请求 浏览器解析htm代码,并请求html代码中的资源(如js、css、图片等) 断开TCP连接 浏览器对页面进行渲染呈现给用户 一、域名解析的详细内部过程 例如,要查询...
  • 性能测试 性能测试实战(一)如何分析一个web端 http请求接口的请求和响应过程http请求响应耗时时长可能与哪些因素有关? 简易分析篇 ​ 文章目录 前言 性能测试 考虑点 时间特性 时间特性 性能测试 性能指标...
  • http请求过程及性能优化分析

    千次阅读 2017-07-17 09:44:08
    http请求当在浏览器中输入地址至获取服务器的相应,总共经历了以下四个步骤: DNS解析在向浏览器输入一个网站时,如www.qq.com,浏览器最终访问的是一个ip地址,也就是说www.qq.com与一个ip存在映射的关系,此时DNS...
  • http请求与响应全过程

    万次阅读 多人点赞 2016-05-24 00:15:10
    4、浏览器给Web服务器发送一个http请求: 5、服务器的永久重定向响应: 6、浏览器跟踪重定向地址: 7、服务器“处理”请求: 8、服务器发回一个HTML响应 9、释放 TCP 连接 10、客户端浏览器解析HTML内容 11、浏览器...
  • 一次完整的HTTP请求过程: 1.首先进行域名解析,域名解析具体过程讲一下: 浏览器搜索自己的DNS缓存,缓存中维护一张域名与IP地址的对应表; 若没有,则搜索操作系统的DNS缓存; 若没有,则操作系统将域名发送至...
  • HTTP协议简介HTTP协议工作原理和流程浏览器在使用HTTP协议时,用户访问网站的流程HTTP协议的请求格式HTTP协议的响应格式状态码重定向的请求代表当前功能还需要后续操作才能完成。 简介 HTTP协议(Hyper Text ...
  • 完整的HTTP请求会经历以下过程

    万次阅读 多人点赞 2017-12-05 15:18:48
    一次完整的Http请求,虽然说的是浏览器,但是换成ios,android也是完全没毛病的。原文http://blog.51cto.com/linux5588/1351007 当我们在浏览器的地址栏输入www.linux178.com,然后回车,回车这一瞬间到看到页面...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 985,934
精华内容 394,373
关键字:

http请求过程