浏览器访问百度全过程

一.通过dns获取百度IP地址.

1.在192.168.1.1这个电脑上用浏览器?访问www.baidu.com的过程如下:1.
当在浏览器?中输www.baidu.com 后按下回?车键之后，浏览器?组织?一个数据包

2.
这个数据包是tcp的格式的数据，这个数据中需要得到对?方的ip以及对?方程序的端?口（?一般情况下?网站的端?口是80）

3.
为了了能够得到www.baidu.com对应的ip地址，因此接下来需要解析这个域名为了了能够解析域名，因此192.168.1.1这个电脑?首先需要发送dns数据包给dns服务器?（dns是?一个
专?门?用来解析域名对应的ip的协议）dns服务器?的ip在电脑能够上?网之前
其实早就已经?自动设定好了了（此时dns服务器?的ip是192.168.2.1）为了了能够发送dns数据包，需要将数据发送给192.168.2.1这个电脑通过检查发现192.168.2.1这个ip和本机的ip不不在同?一个?网段，那么会先将dns数据包发送给默认?网关，但是如果没有默认?网关的mac的话，需要?首先发送arp数据包获取默认?网关的mac，
然后将dns数据包发送给默认?网关(192.168.1.254)，这个电脑接下来将数据转发到互联?网上通过层层的转发，最终这个数据包到达了了
192.168.2.254这个?网关，这个?网关将数据转发给192.168.2.1192.168.2.1这个dns服务器?通过解析接收的数据，将www.baidu.com对应的ip（192.168.3.1）返回给192.168.1.1这个电脑当192.168.1.1这个电脑接收到dns回过来的数据之后，就知道了了www.baidu.com对应的ip（192.168.3.1）

二.通过百度IP访问百度服务器，并返回数据。

接下来将tcp的数据转发给192.168.1.254这个默认?网关
，默认?网关将数据转发到192.168.3.254，然后192.168.3.254将数据转发给192.168.3.1这个服务器?（注意此时收到的数据是tcp的3次握?手的第1次），服务器?接下来和192.168.1.1之间进?行行3次握?手（详情看我上篇博客。）当192.168.1.1建?立连接之后，就会发送真正的数据请求到192.168.3.1这个服务器?上，然后服务器?通过数据的查询最终将数据返回给192.168.1.1当浏览器?收到之后，浏览器?通过渲染
最终?用户看到了了这个?网站上的主?页信息

mac地址和ip地址有什么区别

IP地址，这个应该知道吧，即指使用TCP/IP协议指定给主机的32位地址。IP地址由用点分隔开的4个8八位组构成，如192.168.0.1就是一个IP地址，这种写法叫点分十进制格式。IP地址由网络地址和主机地址两部分组成，分配给这两部分的位数随地址类（A类、B类、C类等）的不同而不同。网络地址用于路由选择，而主机地址用于在网络或子网内部寻找一个单独的主机。一个IP地址使得将来自源地址的数据通过路由而传送到目的地址变为可能。
现在有很多计算机都是通过先组建局域网，然后通过交换机和Internet连接的。然后给每个用户分配固定的IP地址，由管理中心统一管理，这样为了管理方便就需要使用Mac地址来标志用户，防止发生混乱，明确责任（比如网络犯罪）。另外IP地址和Mac地址是有区别的，虽然他们在局域网中是一一对应的关系。IP地址是跟据现在的IPv4标准指定的，不受硬件限制比较容易记忆的地址，而Mac地址却是用网卡的物理地址，多少与硬件有关系，比较难于记忆。
MAC地址，长度为48位（6个字节），通常表示为12个16进制数，每2个16进制数之间用冒号隔开，如：08:00:20:0A:8C:6D就是一个MAC地址，其中前6位16进制数08:00:20代表网络硬件制造商的编号，它由IEEE（Istitute of Electrical and Electronics Engineers，电气与电子工程师协会）分配，而后3位16进制数0A:8C:6D代表该制造商所制造的某个网络产品（如网卡）的系列号。每个网络制造商必须确保它所制造的每个以太网设备都具有相同的前三个字节以及不同的后三个字节。这样就可保证世界上每个以太网设备都具有唯一的MAC地址。
既然每个以太网设备在出厂时都有一个唯一的MAC地址了，那为什么还需要为每台主机再分配一个IP地址呢？或者说为什么每台主机都分配唯一的IP地址了，为什么还要在网络设备（如网卡，集线器，路由器等）生产时内嵌一个唯一的MAC地址呢？主要原因有以下几点：（1）IP地址的分配是根据网络的拓朴结构，而不是根据谁制造了网络设置。若将高效的路由选择方案建立在设备制造商的基础上而不是网络所处的拓朴位置基础上，这种方案是不可行的。（2）当存在一个附加层的地址寻址时，设备更易于移动和维修。例如，如果一个以太网卡坏了，可以被更换，而无须取得一个新的IP地址。如果一个IP主机从一个网络移到另一个网络，可以给它一个新的IP地址，而无须换一个新的网卡。（3）无论是局域网，还是广域网中的计算机之间的通信，最终都表现为将数据包从某种形式的链路上的初始节点出发，从一个节点传递到另一个节点，最终传送到目的节点。数据包在这些节点之间的移动都是由ARP（Address Resolution Protocol：地址解析协议）负责将IP地址映射到MAC地址上来完成的。下面我们来通过一个例子看看IP地址和MAC地址是怎样结合来传送数据包的。
假设网络上要将一个数据包（名为PAC）由临沭的一台主机（名称为A，IP地址为IP_A，MAC地址为MAC_A）发送到北京的一台主机（名称为B，IP地址为IP_B，MAC地址为MAC_B）。这两台主机之间不可能是直接连接起来的，因而数据包在传递时必然要经过许多中间节点（如路由器，服务器等等），我们假定在传输过程中要经过C1、C2、C3（其MAC地址分别为M1，M2，M3）三个节点。A在将PAC发出之前，先发送一个ARP请求，找到其要到达IP_B所必须经历的第一个中间节点C1的MAC地址M1，然后在其数据包中封装（Encapsulation）这些地址：IP_A、IP_B，MAC_A和M1。当PAC传到C1后，再由ARP根据其目的IP地址IP_B，找到其要经历的第二个中间节点C2的MAC地址M2，然后再将带有M2的数据包传送到C2。如此类推，直到最后找到带有IP地址为IP_B的B主机的地址MAC_B，最终传送给主机B。在传输过程中，IP_A、IP_B和MAC_A不变，而中间节点的MAC地址通过ARP在不断改变（M1，M2，M3），直至目的地址MAC_B。

Django请求解析

Django的请求到响应的处理流程本质上差不多，简单来说，都是利用WSGI，针对request，
进行response。当然在响应前会发送request_started信号，会调用预处理函数（在Flask中
是before_request，Django是请求中间件，process_request)，响应完成后会发送
request_finished函数，调用响应后函数（在Flask中是after_request中，Django中是
process_response）。思想差不多，但是处理细节上还是有很多不同的。
1. 用户浏览器一个url，发起一个请求
在Web应用启动后，会生成一个 WSGIHandler 实例(根据setting中的WSGI_APPLICATION
= ‘dailyblog.wsgi.application’ 调用函数），每次请求响应都用这个实例。 settings 里
设置了 WSGI application。返回实例代码：
from django.core.handlers.wsgi import WSGIHandler
def get_wsgi_application():
'''
The public interface to Django's WSGI support. Should return a WSGI
callable.
Allows us to avoid making django.core.handlers.WSGIHandler public API, in
case the internal WSGI implementation changes or moves in the future.
'''
django.setup()
return WSGIHandler()
WSGIHandler继承自BaseHander。这个处理器会导入项目中的 settings模块、导入自定义
例外类，最后调用自己的 load_middleware 方法，加载所有列在 MIDDLEWARE_CLASSES
中的 middleware 类并且内省它们。
2018/7/23 Django 的一次请求到响应的流程
http://www.360doc.com/content/16/0904/10/6902273_588284668.shtml 2/6
BaseHander部分源代码：
class BaseHandler(object):
# Changes that are always applied to a response (in this order).
response_fixes = [
http.conditional_content_removal,
]
def __init__(self):
self._request_middleware = None
self._view_middleware = None
self._template_response_middleware = None
self._response_middleware = None
self._exception_middleware = None
请注意，只有第一次请求时会调用 load_middleware，以后不再调用了。
其中，request_middleware、view_middleware 是顺序，
template_response_middleware、response_middleware、exception_middleware 是逆
序。
一个 middleware 类可以包括请求响应过程的四个阶段：request，view，response 和
exception。对应的方法：process_request，process_view， process_response 和
process_exception。我们在middleware中间件中定义其中的方法。
3、构造WSGIRequest。
WSGIHandler 处理器准备工作已经完成，随后它给调度程序发送一个信号
request_started（这个和Flask中的request_started信号差不多），然后根据入 environ 构
造 WSGIRequest 对象，它的父类是HttpRequest。
4、处理Middleware的request中间件
2018/7/23 Django 的一次请求到响应的流程
http://www.360doc.com/content/16/0904/10/6902273_588284668.shtml 3/6
WSGIHander的get_response方法处理 _request_middleware 实例变量并调用其中的每一
个方法，传入 HttpRequest 的实例作为参数，即请求到达Request Middlewares，中间件对
request做一些预处理，如果中间件返回response，会直接响应请求。
5、 URLConf通过urls.py文件和请求的URL找到相应的视图函数
此时会创建django.core.urlresolvers.RegexURLResolver 的一个实例。
URLresolver 遵循一个相当简单的模式。对于在 URL 配置文件中根据 ROOT_URLCONF 的
配置产生的每一个在 urlpatterns 列表中的条目，它会检查请求的URL 路径是否与这个条目
的正则表达式相匹配，如果是的话，有两种选择：
如果这个条目有一个可以调用的 include，resolver 截取匹配的 URL，转到 include 指定的
URL 配置文件并开始遍历其中 urlpatterns 列表中的每一个条目。根据你 URL 的深度和模块
性，这可能重复好几次。
否则，resolver 返回三个条目：匹配的条目指定的 view function；一个从 URL 得到的未命
名匹配组（被用来作为 view 的位置参数）；一个关键字参数字典，它由从 URL 得到的任意
命名匹配组和从 URLConf 中得到的任意其它关键字参数组合而成。
注意这一过程会在匹配到第一个指定了 view 的条目时停止，因此最好让你的 URL 配置从复
杂的正则过渡到简单的正则，这样能确保 resolver 不会首先匹配到简单的那一个而返回错误
的 view function。
如果没有找到匹配的条目，resolver 会产生 django.core.urlresolvers.Resolver404 异常，
它是 django.http.Http404 例外的子类。后面我们会知道它是如何处理的。
6、开始调用View中相应的视图函数或基于类的视图。
7、View进行一些处理，如通过模型Models返回数据。
8、如果需要，Views可以创建一个额外的Context，Context被当做变量传给Template。
9、Template渲染输出
2018/7/23 Django 的一次请求到响应的流程
http://www.360doc.com/content/16/0904/10/6902273_588284668.shtml 4/6
10、渲染后的输出被返回到View
11、HTTPResponse被发送到Response Middlewares
12、Response Middlewares对response进行特定的处理，然后返回一个新的response
13、Response返回呈现给用户
14、一旦 middleware完成了最后环节，处理器将发送一个信号 request_finished，订阅这
个信号的事件会清空并释放任何使用中的资源。比如，Django 的 request_finished 的订阅
者subscriber会关闭所有数据库连接。
15、所有流程至此已经全部完成。
下面是处理器的源代码：
class WSGIHandler(base.BaseHandler):
initLock = Lock()
request_class = WSGIRequest #创建 WSGIRequest
def __call__(self, environ, start_response):
# Set up middleware if needed. We couldn't do this earlier, because
# settings weren't available.
if self._request_middleware is None:
with self.initLock:
try:
# Check that middleware is still uninitialized.
if self._request_middleware is None:
self.load_middleware()
except:
2018/7/23 Django 的一次请求到响应的流程
http://www.360doc.com/content/16/0904/10/6902273_588284668.shtml 5/6
# Unload whatever middleware we got
self._request_middleware = None
raise
set_script_prefix(get_script_name(environ))
signals.request_started.send(sender=self.__class__, environ=environ)
try:
request = self.request_class(environ)
except UnicodeDecodeError:
logger.warning('Bad Request (UnicodeDecodeError)',
exc_info=sys.exc_info(),
extra={
'status_code': 400,
}
)
response = http.HttpResponseBadRequest()
else:
response = self.get_response(request)
response._handler_class = self.__class__
status = '%s %s' % (response.status_code, response.reason_phrase)
response_headers = [(str(k), str(v)) for k, v in response.items()]
for c in response.cookies.values():
response_headers.append((str('Set-Cookie'), str(c.output(header=''))))
start_response(force_str(status), response_headers)
if getattr(response, 'file_to_stream', None) is not None and environ.get('wsgi.file_wrapper'):
response = environ['wsgi.file_wrapper'](response.file_to_stream)
return respons
2018/7/23 Django 的一次请求到响应的流程
http://www.360doc.com/content/16/0904/10/6902273_588284668.shtml 6/6
异常情况：
如果 view 函数，或者其中的什么东西，发生了异常，那么 get_response将遍历它的
_exception_middleware 实例变量并呼叫那里的每个方法，传入 HttpResponse 和这个
exception 作为参数。如果顺利，最后会实例化，并返回一个 HttpResponse 。
这时候有可能还是没有得到一个 HttpResponse，这可能有几个原因：
view 并没有返回内容。
view 可能抛出了异常，但middleware没有能处理它。
一个 middleware 方法试图处理一个异常时，自己又产生了一个异常。
处理器会做些相应的异常处理，如404，403，500等等，具体可以看上面的源代码。
里面有些地方是参考其他博客文章，但忘了地址了。如有原作者看到，请给予提示，谢谢。

关于Django的网络请求过程保存下!相关推荐

WireShark 探索网络请求过程（五层网络模型、三次握手、滑动窗口协议）
当我们在浏览器输入URL点击确认后,浏览器展示出网页信息.可你曾想过这其中的过程是怎样的?理论性较强的朋友可能知道后续DNS会解析地址,然后TCP/IP三次握手建立起连接,紧接着客户端与服务器开始传 ...
WireShark抓包图解探索网络请求过程（五层网络模型、三次握手、滑动窗口协议）
当我们在浏览器输入URL点击确认后,浏览器展示出网页信息.可你曾想过这其中的过程是怎样的?理论性较强的朋友可能知道后续DNS会解析地址,然后TCP/IP三次握手建立起连接,紧接着客户端与服务器开始传输 ...
MKNetwork网络请求过程中onCompletion调用两次的问题
MKNetwork在网络请求过程中,MKNetworkOperation操作同一个url请求(GET请求)时会调用两次onCompletion. 这样会引起两次的数据问题. 现在一种解决方法. if ...
【Android开发】计算机网络基础知识点，如何完成网络请求过程？
(一)计算机网络基础知识:从一次完整的网络请求过程分析 (1)域名解析 1.1)域名与ip地址 (1)ip地址:ip地址是一个32位(4字节)的二进制数(IPV4),常见格式为:192.168.1.1 ...
从浏览器键入url后分析网络请求过程
当我们在浏览器中键入URL并回车,例如:小编在浏览器的地址栏中键入www.baidu.com后就打开了百度的首页,那么在这个过程中到底发生了一些什么呢?下面就由小编带大家来了解一下. 互联网的基本概念 ...
NetWork——描述一次完整的网络请求过程
0. 前言从我们在浏览器的地址栏输入http://blog.csdn.net/seu_calvin后回车,到我们看到该博客的主页,这中间经历了什么呢?简单地回答这个问题,大概是经历了域名解析.TC ...
android 设置允许http请求_网络请求框架----OkHttp原理
一.前言在 Android 中,网络请求是一个必不可少的功能,因此就有许多代表网络请求客户端的组件库,具有代表性的有下面三种: Apache 的 HTTP 客户端组件 HttpClient. Jav ...
网络请求框架：Okhttp：Call对象实现请求源码解析【四】
OKHttp3--调用对象RealCall源码解析[四]_没有鱼了的博客-CSDN博客一:概述,当我们封装好 Request后需要执行这个请求,但是 OkHttp并不是直接执行 Request ,而 ...
网络请求No peer certificate
我们在更换服务器或者转为https的时候,在进行请求时产生异常 javax.net.ssl.SSLPeerUnverifiedException: No peer certificateW/Syste ...

关于Django的网络请求过程保存下!