浏览器一个请求过程

整个流程如下:
  域名解析
  为了将消息从你的PC上传到服务器
  上.需要用到1P协议、ARP协议和0SPF协议
  发起TCP的3次握手
  建立TCP连接后发起http请求
  服务器响应htp请求
  浏览器解析htm代码,并请求html代码中的资源(如js、css、图片等)
  断开TCP连接
  浏览器对页面进行渲染呈现给用户

一、域名解析的详细内部过程   

例如,要查询www.baidu.com的IP地址(DNS解析url):

浏览器搜索自己的DNS缓存(维护一张域名与IP地址的对应表)

若没有,则搜索操作系统中的DNS缓存(维护一张域名与IP地址的对应表)

若没有,则搜索操作系统的hosts文件(Windows环境下,维护一张域名与IP地址的对应表,位置一般在 C:\Windows\System32\drivers\etc\hosts)

若没有,则操作系统将域名发送至 本地域名服务器- -(递归查询方式),本地域名服务器 查询自己的DNS缓存,查找成功则返回结果,否则,(以下是迭代查询方式)

4.1 本地域名服务器 向根域名服务器(其虽然没有每个域名的具体信息,但存储了负责每个域,如com、net、org等的解析的顶级域名服务器的地址)发起请求,此处,根域名服务器返回com域的顶级域名服务器的地址

4.2 本地域名服务器 向com域的顶级域名服务器发起请求,返回baidu.com权限域名服务器(权限域名服务器,用来保存该区中的所有主机域名到IP地址的映射)地址

4.3 本地域名服务器 向baidu.com权限域名服务器发起请求,得到www.baidu.com的IP地址

本地域名服务器 将得到的IP地址返回给操作系统,同时自己也将IP地址缓存起来

操作系统将 IP 地址返回给浏览器,同时自己也将IP地址缓存起来

至此,浏览器已经得到了域名对应的IP地址

二、三次握手

第一次握手:主机A发送位码为syn=1,随机产生seq number=x的数据包到服务器,客户端进入SYN_SEND状态,等待服务器的确认;主机B由SYN=1知道,A要求建立联机;

第二次握手:主机B收到请求后要确认联机信息,向A发送ack number(主机A的seq+1),syn=1,ack=1,随机产生seq=y的包,此时服务器进入SYN_RECV状态;

第三次握手:主机A收到后检查ack number是否正确,即第一次发送的seq number+1,以及位码ack是否为1,若正确,主机A会再发送ack number(主机B的seq+1),ack=1,主机B收到后确认seq值与ack=1则连接建立成功。客户端和服务器端都进入ESTABLISHED

态,完成TCP三次握手。

TCP位码,有6种标示:SYN(synchronous建立联机) ACK(acknowledgement 确认) PSH(push传送) FIN(finish结束) RST(reset重置) URG(urgent紧急)

Sequence number(顺序号码) Acknowledge number(确认号码)

三、建立TCP连接后发起http请求

四、服务器收到请求并响应HTTP请求

1.负载均衡
         网站可能会有负载均衡设备来平均分配所有用户的请求。即对工作任务进行平衡,分
摊到多个操作单元上执行,如图片服务器,应用服务器等。
2请求处理阅读请求及它的参数和 cookies

五.浏览器解析htm代码,并请求htm代码中的资源(如js、css图片等)

  看是否是长连接。来决定是不是断开TCP连接

六.断开TCP连接

四次挥手

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

第二次挥手:主机2收到了主机1发送的FIN报文段,向主机1回一个ACK报文段,Acknowledgment NumberSequence Number加1;主机1进入FIN_WAIT_2状态;主机2告诉主机1,我也没有数据要发送了,可以进行关闭连接了;

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

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

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

重新温习下网络模型:

  • 七层结构(至顶向下):应用层、表示层、会话层、传输层、网络层、数据链路层、物理层

client(浏览器) 与Server 通过HTTP协议通讯,HTTP协议属于”应用层协议”;HTTP基于TCP协议,TCP通过Socket进行通讯,TCP 被称为“传输层协议”。而HTTPS 还需要走会话层SSL\TLS等协议;传输层之下是网络层,这里主要是路由协议OSPF等进行路由选择,转发;再向下数据链路层主要是ARP、RARP协议完成IP和MAC地址互相解析,再向下是物理层主要是基于IEEE802.X等协议进行数据比特流转成高低电平的定义;

当浏览器发出请求时候,首先通过应用层DNS协议得到对应IP地址,在这经历全球路由大接力;而传输层TCP协议采用“三次握手”协议建立连接和“四次挥手”协议断开连接,然后数据链路层解析IP与MAC地址的映射;数据经过层层数据封包、解包过程,如下:

   

    这里特别强调下三次握手建立连接,放图作为参考:

    

四次握手断开连接:

客户端发起 FIN ACK, 服务端应答 ACK, 待服务端数据发送完成后,发送FIN ACK, 客户端应答 ACK, 连接断开。

从应用服务角度分析

数据交换主要通过HTTP 协议, HTTP协议是无状态协议。多数通过GET、POST方法,GET与POST区别:
GET:请求获取指定的资源,不改变服务器状态,GET方法是幂等的,GET方法的报文主体没有任何语义。
POST: 根据请求报文主体对指定的资源做出处理,改变服务器状态,POST方法不幂等。

http方法不仅只有GET、POST, http1.1中含有如下方法:

RESTful API 就是利用这组方法来统一表述资源的状态转化。

同时,由于http无状态协议的特点,服务端需要记录用户时,就需要用某种机制来识具体的用户, 通常采用cookies、session。

session 本意是会话,是一个抽象概念。将 clinet 和 server 之间一对一的交互,抽象为“会话”,开发者为了实现一对一的“隔离”,中断和继续等操作,进而衍生出“会话状态”,也就是 session 的概念。

如何维护这个session概念,很自然的想到在http请求报文中加入登录标识就可以了,这个登录标识就是cookie。而 cookie 是一个实际存在的东西,http 协议中定义在 header 中的字段。这种技术的实现就是利用了cookie技术。 cookie是存储key-value对的一个文件,务必记住,它是由服务器将cookie添加到response里一并返回给客户端,然后客户端会自动把response里的cookie接收下来,并且保存到本地,下次发出请求的时候,就会把cookie附加在request里,服务器在根据request里的cookie遍历搜索是否有与之符合的信息。

cookie 虽然很方便,但是使用 cookie 有两个的弊端:

  1. cookie 中的所有数据在客户端就可以被修改。这就意味着数据非常容易被伪造,一些重要的数据就不能存放在 cookie 中;
  2. 如果 cookie 中数据字段太多会影响传输效率;

为了解决这些问题,就产生了 session,
session是一种服务器机制,使用Hash散列表结构来保存信息。
1. 每个 session 都对应一个 session_id,通过 session_id 可以查询到对应的 session;
2. session_id 通常是存放在客户端的 cookie 中,服务端存好 session 之后将对应的 session_id 设置在 cookie 中发送给客户端;
3. 当请求到来时,服务端检查 cookie 中保存的 session_id 并通过这个 session_id 与服务器端的 session 关联起来,进行数据的保存和修改;

这就是大多数人通常所说的session, 这里其实是指的 session实现。

server 端通常采用Nginx、Apache;

这里以PHP为例:
Nginx接收到请求,进行一些验证,如黑白名单拦截等, 是否有限流限制,是否有负载均衡设置;
如果请求的是静态内容,Nginx会将结果直接返回给用户。
如果请求的是动态内容,Nginx会将请求交给fastcgi客户端, 通过fastcgi_pass将这个请求发送给进程php-fpm。Nginx 不支持对外部动态程序的直接调用或者解析 ,所有的外部程序必须通过FastCGI接口来调用。

原文地址:https://www.cnblogs.com/dangkai/p/10431556.html

时间: 2024-10-13 07:38:18

浏览器一个请求过程的相关文章

RestTemplate的一个请求过程,mark一下

17:14:36.979 [main] DEBUG org.springframework.web.client.RestTemplate - Created GET request for "http://localhost:8080/test/session/get" 17:14:36.992 [main] DEBUG org.springframework.web.client.RestTemplate - Setting request Accept header to [ap

和浏览器异步请求取消相关的那些事

我们开发web页面时候,也许会遇到和异步请求取消相关的问题. 如:在一个请求发送之后,用户做了一个取消指令,为了节省资源,我们需要把已经被用户取消的请求终止掉:或者是一个页面正在用ajax请求后台,突然页面发生了跳转,而我们未完成的ajax莫名其妙地走进了error里面了. 为了解决这两问题,我们今天一起看看和异步请求取消相关的那些事. 1.ajax的取消 当我们创建一个XMLHttpRequest对象的时候,我们就会发现两个api——abert和onabort,这就是终止异步请求的方法与其响应

chrome 浏览器的预提取资源机制导致的一个请求发送两次的问题以及ClientAbortException异常

调查一个 pdf 打印报错: ExceptionConverter: org.apache.catalina.connector.ClientAbortException: java.net.SocketException: Software caused connection abort: socket write error at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:407)

浏览器的一个请求从发送到返回经历了什么(转)

1.先从网络模型的层面: cilent与server通过http协议通讯,http协议属于应用层协议,http基于tcp协议,所以cilent与server主要通过socket进行通讯:tcp属于运输层协议,如果走https还需要会话层TLS.SSL等协议:同时还需要DNS域名解析等:传输层之下网络层,这里主要是路由协议OSPF.RIp等进行路由转发之类的.再向下数据链路层主要是ARP.RARP协议完成IP和MAC地址的互解析,再向下到最底层物理层基本就是IEEE802.X等协议进行数据比特流转

简单说下浏览器处理请求的过程

先来个图 和前端不太想干的东西我已过滤掉,不然的话你一时伴儿真说不完,我们只是说最主要的: 当一个用户在浏览器里输入www.google.com这个URL时,将会发生如下操作: 首先,浏览器会请求DNS把这个域名解析成对应的IP地址: 然后,根据这个IP地址在互联网上找到对应的服务器,建立Socket连接,向这个服务器发起一个HTTP Get请求,由这个服务器决定返回默认的数据资源给访问的用户: 在服务器端实际上还有复杂的业务逻辑:服务器可能有多台,到底指定哪台服务器处理请求,这需要一个负载均衡

一个完整的HTTP请求过程详细

整个流程1.域名解析 —> 2.与服务器建立连接 —> 3.发起HTTP请求 —>4. 服务器响应HTTP请求,浏览器得到html代码 —> 5.浏览器解析html代码,并请求html代码中的资源(如js.css.图片) —> 6.浏览器对页面进行渲染呈现给用户 1. 域名解析 以Chrome浏览器为例: ① Chrome浏览器 会首先搜索浏览器自身的DNS缓存(缓存时间比较短,大概只有1分钟,且只能容纳1000条缓存),看自身的缓存中是否有https://www.cnblo

.net 浏览器请求过程(图)

大致: 细节: (信息来源于传智播客教学视频) .net 浏览器请求过程(图)

Django处理一个请求的过程

一.Django处理一个请求的过程 Django处理一个请求的过程如下: Django使用的是根URLconif模块,这个值通常通过ROOT_URLCONF设置:url到视图函数的映射关系(在.../settings.py文件中) Django加载URLconf模块(urls.py),并寻找可用的urlpatterns,匹配规则参考二 Django依次匹配每个URL模式,在与请求的URL匹配的第一个模式处停下来 一旦其中一个正则表达式匹配上,则Django将请求指向对应的视图函数处理 如果没有匹

浏览器的一个请求从发送到返回都经历了什么

我大概讲下我的答案: 1.先从网络模型层面: client (浏览器)与 server 通过 http 协议通讯,http 协议属于应用层协议,http 基于 tcp 协议,所以 client 与 server 主要通过 socket 进行通讯: 而 tcp 属于传输层协议.如果走 https 还需要会话层 TLS.SSL 等协议: 传输层之下网络层,这里主要是路由协议 OSPF 等进行路由转发之类的.再向下数据链路层主要是 ARP.RARP 协议完成 IP 和 Mac 地址互解析,再向下到最底