标签：HTTP 请求 报文 计算机网络 响应 服务器 DHCP
一、概述
1. 互联网基础结构发展的三个阶段
第一阶段：是从单个网络ARPANET向互联网发展的过程
第二阶段：的特点是建成了三级结构的互联网
第三阶段：的特点是逐渐形成了多层次ISP结构的互联网
互联网交换点IXP的主要作用就是允许两个网络直接相连并交换分组
互联网的组成
- 边缘部分：有所有链接在互联网上的主机组成。这部分是用户直接使用的，用来进行通信和资源共享
- 核心部分 由大量网络和连接这些网络的路由器组成。这部分是为边缘部分提供服务的
边缘部分
在网络边缘的端系统之间的通信方式通常可以划分为两大类：客户-服务器方式（C/S方式）和对等方式（P2P）方式
核心部分
在网络核心部分起特殊作用的是路由器。路由器是实现分组交换的关键构建，起任务是转发收到的分组。
电路交换
交换方式：“建立连接（占用通信资源）->通话（一直占用通信资源）->释放连接（归还通信资源）
重要特点：在通话的全部时间内，通话的两个用户始终占用端到端的通信资源
分组交换
分组交换采用存储转发技术。在发送报文之前，先把较长的报文划分成一个个更小的等长数据段，在每个数据段前面加上一些由一些必要的控制信息组成的首部后，就构成了一个分组。
那么路由器是怎么进行分组转发的呢？路由器收到一个分组，先暂时存储一次啊，检查其首部，查找转发表，按照首部中 的目的地址，找到合适的接口转发出去，把分组交给下一个路由器。这样一步步地以存储转发的方式，把分组交付最终目的的主机。
分组交换也会带来一些新的问题，例如，分组在各路路由器存储转发时需要排队，这就会造成一定的时延。
计算机网络的定义
计算机网络主要是由一些通用的、可编程的硬件互联而成，而这些硬件并非专门用来实现某一特定目的。这些可编程的硬件能够用来传送多种不同的数据类型，并能支持广泛的和日益增长的应用。
计算机网络的体系结构
-
应用层
应用层是体系结构中的最高层。应用层的任务是通过进程间的交互来完成特定网络应用。应用层协议定义的是应用进程间通信和交互的规则。我们把应用层交互的数据单元称为报文（message）。
-
运输层
运输层的任务就是负责向两台主机中进程之间的通信提供通用的数据传输服务。
运输层主要使用以下两种协议：
-
传输控制协议TCP——提供面向连接的、可靠的数据传输服务，其数据传输的单位是报文段。
-
用户数据报协议UDP——提供无连接的、尽最大努力的数据传输服务（不保证数据传输的可靠性），其数据传输的单位是用户数据报。
-
-
网络层
网络层负责为分组交换网上的不同主机提供通信服务。在发送数据时，网络层吧运输层产生的报文段或用户数据封装成分组或包进行传送。在TCP/IP体系中，由于网络层使用IP协议，因此分组也叫做IP数据报，或简称数据报。
-
数据链路层
数据链路层常简称为链路层。在两个相邻节点之间传送数据时，数据链路层将网络层交下来的IP数据报组装成帧，在两个相邻结点间的链路上传送帧。，每一帧包括数据和必要的控制信息（如同步信息、地址信息、差错控制等）。
-
物理层
在物理层上所传送数据的单位是比特。
二、DHCP
为了省去给计算机配置IP地址的麻烦，动态主机配置协议DHCH提供了一种机制，允许一台计算机加入新的网络和获取IP地址而不用手工参与。
DHCP使用客户服务器方式。常用的2个端口：67(DHCP服务器端口)，68(DHCP客户端端口)。
-
需要IP地址的主机在启动时就向DHCP服务器发送 发现报文 （将目的IP地址置为全1，即255.255.255.255），这时该主机就成为了DHCP客户。
-
由于不知道DHCP服务器在哪，所以需要发送广播报文，并且这台主机目前还没有自己的IP地址，所以将IP数据报的源IP地址设为全0.这样，在本地网络上的所有主机都能够收到这条广播报文，但只有DHCP服务器才对此广播报文进行回答。
-
DHCP先在其数据库中查找该计算机的配置信息。若找到，则返回找到的信息。若找到不到，则从服务器的IP地址池中取一个地址分配给该计算机。DHCP服务器的回答报文叫做提供报文，表示“提供”了IP地址等配置信息。
-
但是在每一个网络上都设置一个DHCP服务器就太多了。因此现在是使每一个网络至少有一个DHCP中继代理（通常是一台路由器）。它配置了DHCP服务器的IP地址信息。当DHCP中继代理收到主机A以广播形式发送的发现报文后，就以单播方式向DHCP服务转发此报文，并等待其回答。收到DHCP服务器回答的提供报文后，DHCP中继代理再把此提供报文发回给主机A。
- DHCP服务器分配给DHCP客户的IP地址是临时的，因此DHCP客户只能在一段有限时间内使用这个分配到的IP地址。
HTTP
URL
URL全称统一资源定位符，顾名思义，就是给资源的位置定位的识别方法。也就是人们常说的网址。
URL的一般形式由以下四个部分组成：
<协议>://<主机>:<端口>/<路径>
这里的<协议>就是指出使用什么协议来获取该万维网文档。现在最常用的就是http协议（超文本传送协议HTTP），其次是ftp（文件传送协议FTP）。
主机是指该主机在互联网上的域名，在后面是第三部分第四部分<端口>和<路径>，有时可省略。
HTTP
HTTP协议定义了浏览器怎样向万维网服务器请求万维网文档，以及服务器怎样把文档传送给浏览器。从层次的角度看，HTTP是面向事务的应用层协议。
事务就是指一系列的信息交换，而这一系列的信息交换是一个不可分割的整体，也就是说，要么所有信息都交换完成，要么一次交换都不进行。
每个万维网网点都有一个服务器进程，它不断监听TCP的端口80，以便发现是否有浏览器向它发出连接建立请求。一旦监听到连接建立请求并建立TCP连接之后，浏览器就向万维网服务器发出浏览某个浏览器和服务器之间的请求和响应的交互，必须按照规定的格式和遵循一定的规则。这些协议和规则就是超文本传送协议HTTP。
HTTP协议本身是无连接的。这就是说，虽然HTTP使用了TCP连接，但通信的双方在交换HTTP报文之前不需要先建立HTTP连接。
HTTP协议是无状态的。也就是说，同一个客户访问同一个服务器上的页面时，服务器并不记得曾经访问过的这个客户，也不记得为该客户曾经服务过多少次，HTTP的无状态特性简化了服务器的设计，使得服务器更容易支持大量并发的HTTP请求。
HTTP/1.0与HTTP/1.1
我们粗略估算一下，从浏览器请求一个万维网文档到收到整个文档所需的时间（如图）。用户在点击鼠标链接某万维网时，HTTP协议首先要和服务器建立TCP连接。这需要使用三报文握手。当建立TCP连接的三报文握手的前两部分完成后，万维网客户就把HTTP请求报文，作为建立TCP连接的三报文握手中的第三个报文的数据，发送给万维网服务器。服务器收到HTTP请求报文后，就把所请求的文档作为响应报文返回给客户。
可以看出，请求一个万维网文档所需的时间是该文档的传输时间，加上两倍往返时间RTT（一个RTT用于连接TCP连接，另一个RTT用于请求和接受万维网文档）。
HTTP/1.0是非持续连接（短链接）。即每请求一个文档就要有两倍RTT的开销。还有一种开销就是万维网客户和服务器每建立一次新的TCP连接都要分配缓存和变量，特别是万维网服务器往往要同时服务与大量客户请求。这是HTTP/1.0一大缺点。
HTTP/1.1是持续连接（长连接）。所谓持续连接就是万维网服务器在发送响应后仍然在一段时间内保持这条连接，使同一客户和该服务器可以继续在这条连接上传送后续的HTTP请求和响应报文。这并不局限于传送同一个页面上链接的文档，而是只要这些文档都在同一个服务器上就行。
HTTP/1.1协议的持续连接有两种工作方式，即，非流水线方式和流水线方式。
非流水线方式的特点，是客户在收到前一个响应后才能发出下一个请求。因此，在TCP连接已建立后，客户每访问一次对象都要用去一个往返时间RTT。这比非持续连接要用去两倍RTT的开销，节省了建立TCP连接所需要的一个RTT时间。但非流水线方式还是有缺点的，因为服务器在发送完一个对象后，其TCP连接就处于空闲状态，浪费了服务器资源。
流水线方式的特点，是客户在收到HTTP的响应报文之前就能够接着发送新的请求报文。于是一个接一个的请求报文到达服务器后，服务器就可以连续发回响应报文。因此，使用流水线方式时，客户访问所有的对象只需花费一个RTT时间。流水线工作方式使TCP连接中的空闲时间减少，提高了下载文档的效率。
代理服务器
代理服务器是一种网络实体，它又称为万维网高速缓存（Web cache）。代理服务器把最近的一些请求和响应暂存在本地磁盘中。当新请求到达时，若代理服务器发现这个请求与暂存放的请求相同，就返回暂存的响应，而不需要按URL的地址再去互联网访问该资源。代理服务器可在客户端或服务器端工作，也可以在中间系统上工作。
HTTP的报文结构
HTTP有两类报文：
（1）请求报文——从客户向服务器发送请求报文
（2）响应报文——从服务器到客户的回答
由于HTTP是面向文本的（text-oriented），因此在报文中的每一个字段都是一些ASCII码串，因而各个字段的长度都是不确定的。
HTTP请求报文和响应报文都是由三个部分组成的，可以看出，这两种报文格式的区别就是开始行不同。
- 开始行，用于区分是请求报文还是响应报文。在请求报文中的开始行叫做请求行，而在响应报文中的开始行叫做状态行。在开始行的三个字段之间都以空格分隔开，最后的“CR”和“LF”分别代表“回车”和“换行”。
- 首部行，用来说明浏览器、服务器或报文主体的一些信息。首部可以有好几行，但也可以不使用。在每一个首部行中都有首部字段名和它的值，每一行在结束的地方都要有“回车”和"换行"。整个首部行结束时，还有一空行将首部行和后面的实体主体分开。
- 实体主体，在请求报文中一般都不用这个字段，而在响应报文中也可能没有这个字段。
请求报文的第一行“请求行”只有三个内容，即方法，请求资源的url，以及HTTP的版本。
HTTP请求报文的一些方法
| 方法（操作） | 意义 |
|---|---|
| OPTION | 请求一些选项的信息 |
| GET | 请求读取由URL所标志的信息 |
| HEAD | 请求读取由URL所标志的信息的首部 |
| POST | 给服务器添加信息（例如，注释） |
| PUT | 在指明的URL下存储一个文档 |
| DELETE | 删除指明的URL所标志的资源 |
| TRACE | 用来进行环回测试的请求报文 |
| CONNECT | 用于代理服务器 |
每一个请求报文发出后，都能收到一个响应报文。响应报文的第一行就是状态行。
状态行包括三项内容，即HTTP的版本，状态码，以及解释状态码的简单短语。
状态码都是三位数字的，分为五大类：
1xx 表示通知信息，如请求收到了或正在进行处理
这个临时响应表明，迄今为止的所有内容都是可行的，客户端应该继续请求，如果已经完成，则忽略它。
2xx 表示成功，如接受或知道了
请求成功。成功的含义取决于HTTP方法：
- GET：资源已被提取并在消息正文中传输。
- HEAD：实体标头位于消息正文中。
- POST：描述动作结果的资源在消息体中传输。
- TRACE：消息正文包含服务器收到的请求消息
请求已经接收到，但还未响应，没有结果。意味着不会有一个异步的响应去表明当前请求的结果，预期另外的进程和服务去处理请求，或者批处理。
服务器成功处理了请求，但不需要返回任何实体内容，并且希望返回更新了的元信息。响应可能通过实体头部的形式，返回新的或更新后的元信息。如果存在这些头部信息，则应当与所请求的变量相呼应。如果客户端是浏览器的话，那么用户浏览器应保留发送了该请求的页面，而不产生任何文档视图上的变化，即使按照规范新的或更新后的元信息应当被应用到用户浏览器活动视图中的文档。由于204响应被禁止包含任何消息体，因此它始终以消息头后的第一个空行结尾。
3xx 表示重定向，如要完成请求还必须采取进一步的行动
被请求的资源已永久移动到新位置，并且将来任何对此资源的引用都应该使用本响应返回的若干个 URI 之一。如果可能，拥有链接编辑功能的客户端应当自动把请求的地址修改为从服务器反馈回来的地址。除非额外指定，否则这个响应也是可缓存的。
4xx 表示客户端的差错，如请求中有错误的语法或不能完成
1、语义有误，当前请求无法被服务器理解。除非进行修改，否则客户端不应该重复提交这个请求。
2、请求参数有误。
请求失败，请求所希望得到的资源未被在服务器上发现。没有信息能够告诉用户这个状况到底是暂时的还是永久的。假如服务器知道情况的话，应当使用410状态码来告知旧资源因为某些内部的配置机制问题，已经永久的不可用，而且没有任何可以跳转的地址。404这个状态码被广泛应用于当服务器不想揭示到底为何请求被拒绝或者没有其他适合的响应可用的情况下。
5xx 表示服务器的差错，如服务器失效无法完成请求
服务器遇到了不知道如何处理的情况。
服务器没有准备好处理请求。 常见原因是服务器因维护或重载而停机。 请注意，与此响应一起，应发送解释问题的用户友好页面。 这个响应应该用于临时条件和 Retry-After：如果可能的话，HTTP头应该包含恢复服务之前的估计时间。 网站管理员还必须注意与此响应一起发送的与缓存相关的标头，因为这些临时条件响应通常不应被缓存。
在服务器上存放用户的信息
cookie是这样工作的。当用户A浏览某个使用Cookie的网站时，该网站的服务器就为A产生一个唯一的识别码，并以此作为索引在服务器的后端数据库中产生一个项目。接着在给A的HTTP响应报文中添加一个叫做Set-cookie的首部行。这里的“首部字段名”就是“Set-cookie”，而后面的“值”就是赋予该用户的“识别码”。
当A收到这个响应时，其浏览器就在它管理的特定Cookie文件中添加一行，其中包括这个服务器的主机名和Set-cookie后面给出的识别码。当A继续浏览这个网站时，每发送一个HTTP请求报文，其浏览器就会从其cookie文件中取出这个网站的识别码，并放到HTTP请求报文的Cookie首部行中。
于是这个网站就能跟踪用户在该网站的活动。如果A在几天后再次访问这个网站，那么它的浏览器会在其HTTP请求报文中继续使用该首部行cookie，而这个网站服务器根据A过去的访问记录可以向他推荐商品，和他登记过的信用卡付费等操作。
需要注意的是，cookie只是一个小小的文本文件，不是计算机的可执行程序，因此不可能传播计算机病毒，也不可能用来获取用户计算机硬盘中的信息。但是会泄露用户的隐私，例如，网站服务器知道了A的一些信息，就有可能把这些信息出卖给第三方。
Cookie首部行中。
于是这个网站就能跟踪用户在该网站的活动。如果A在几天后再次访问这个网站，那么它的浏览器会在其HTTP请求报文中继续使用该首部行cookie，而这个网站服务器根据A过去的访问记录可以向他推荐商品，和他登记过的信用卡付费等操作。
需要注意的是，cookie只是一个小小的文本文件，不是计算机的可执行程序，因此不可能传播计算机病毒，也不可能用来获取用户计算机硬盘中的信息。但是会泄露用户的隐私，例如，网站服务器知道了A的一些信息，就有可能把这些信息出卖给第三方。
标签：HTTP,请求,报文,计算机网络,响应,服务器,DHCP 来源： https://blog.csdn.net/qq_45902611/article/details/115646816
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。