一, TCP/IP 的分层管理
1. 首先分为 4 层: 应用层, 传输层, 网络层, 链路层.
应用层: 决定了向用户提供应用服务时通信的活动. TCP/IP 协议族内预存了各类通用的应用服务. 比如, FTP(File
Transfer Protocol, 文件传输协议) 和 DNS(Domain Name System, 域名系统) 服务就是其中两类. 此外, HTTP 也属于这一层.
传输层: 传输层对上层应用层, 提供处于网络连接中的两台计算机之间的数据传输. 在传输层有两个性质不同的协议: TCP(Transmission Control Protocol, 传输控制协议) 和 UDP(User Data Protocol, 用户数据报协议) .
网络层(又名网络互连层): 用来处理在网络上流动的数据包. 数据包是网络传输的最小数据单位. 该层规定了通过怎样的路径(所谓的传输路线) 到达对方计算机, 并把数据包传送给对方, 网络层所起的作用就是在众多的选项内选择一条传输路线.
链路层(又名数据链路层, 网络接口层): 用来处理连接网络的硬件部分. 包括控制操作系统, 硬件的设备驱
动, NIC(Network Interface Card, 网络适配器, 即网卡) , 及光纤等物理可见部分(还包括连接器等一切传输媒介) . 硬件上的范畴均在链路层的作用范围之内.
2.TCP/IP 通信传输流参看下图
发送端在层与层之间传输数据时, 每经过一层时必定会被打上一个该层所属的首部信息. 反之, 接收端在层与层传输数据时, 每经过一层时会把对应的首部消去. 其实包装数据信息的过程就是封装.
二, HTTP 协议:
1. 负责传输的 IP 协议:
作用是把各种数据包传送给对方. 而要保证确实传送到对方那里, 则需要满足各类条件. 其中两个重要的条件是 IP 地址和 Mac 地址(Media Access Control Address) . 这两个地址的差别: IP 地址指明了节点被分配到的地址, Mac 地址是指网卡所属的固定地址. IP 地址可以和 Mac 地址进行配对. IP 地址可变换, 但 Mac 地址基本上不会更改.
1),APR 协议:
用以解析地址的协议, 根据通信方的 IP 地址就可以反查出对应的 Mac 地址, 即在信号传输的过程中, 一般会暴露 IP 地址, 可以通过 ARP 协议, 解析 IP 地址, 找到对应的 Mac 地址. 如下图:
ARP 解析原理: 1, 每个主机都会在自己的 ARP 缓冲区中建立一个 ARP 列表, 以表示 IP 地址和 Mac 地址之间的对应关系.
2, 当源主机要发送数据时, 首先检查 ARP 列表中是否有对应 IP 地址的目的主机的 Mac 地址, 如果有, 则直接发送数据, 如果没有, 就向本网段的所有主机发送 ARP 数据包, 该数据包包括的内容有: 源主机 IP 地址, 源主机 Mac 地址, 目的主机的 IP 地址.
3, 当本网络的所有主机收到该 ARP 数据包时, 首先检查数据包中的 IP 地址是否是自己的 IP 地址, 如果不是, 则忽略该数据包, 如果是, 则先从数据包中取出源主机的 IP 和 Mac 地址写入到 ARP 列表中, 如果已经存在, 则覆盖, 然后将自己的 Mac 地址写
入 ARP 响应包中, 告诉源主机自己是它想要找的 Mac 地址.
4, 源主机收到 ARP 响应包后. 将目的主机的 IP 和 Mac 地址写入 ARP 列表, 并利用此信息发送数据. 如果源主机一直没有收到 ARP 响应数据包, 表示 ARP 查询失败.
广播发送 ARP 请求, 单播发送 ARP 响应.
2.TCP 协议:
参照这个: https://blog.csdn.net/striveb/article/details/84063712
3.DNS 协议:
提供域名到 IP 地址之间的解析服务. 我们平时在访问网站的时候, 一般都是输入英文字母, 比如: www.baidu.com, 这就是域名, 而我们的服务器和协议一般都无法识别域名的, 这个时候就需要将他们转换为数字, 即 IP 地址, DNS 就是干这个事的. DNS 协议提供通过域名查找 IP 地址, 或逆向从 IP 地址反查域名的服务.
接下来, 我们就来看看访问一个网站的整个过程:
4.URL 和 URI
URL: 统一资源定位符, 即我们平时访问的网址等待路径.
URI: 由某个协议方案表示的资源的定位标识符. 协议方案是指访问资源所使用的协议类型名称. 比如采用 HTTP 协议时, 协议方案就是 HTTP.URI 用字符串标识某一互联网资源, 而 URL 表示资源的地点(互联网上所处的位置) . 可见 URL 是 URI 的子集.
5.HTTP 协议
(1)HTTP 简介
HTTP 协议规定, 请求从客户端发出, 最后服务器端响应该请求并返回. 换句话说, 肯定是先从客户端开始建立通信的, 服务器端在没有接收到请求之前不会发送响应. 先看下面这个例子:
起始行开头的 GET 表示请求访问服务器的类型, 称为方法(method) . 随后的字符串 /index.htm 指明了请求访问的资源对象,
也叫做请求 URI(request-URI) . 最后的 HTTP/1.1, 即 HTTP 的版本号, 用来提示客户端使用的 HTTP 协议功能.
综合来看, 这段请求内容的意思是: 请求访问某台 HTTP 服务器上的 / index.htm 页面资源. 请求报文是由请求方法, 请求 URI, 协议版本, 可选的请求首部字段和内容实体构成的.
(2)HTTP 是不保存状态的协议
HTTP 是一种不保存状态, 即无状态(stateless) 协议. HTTP 协议自身不对请求和响应之间的通信状态进行保存. 也就是说在 HTTP 这个级别, 协议对于发送过的请求或响应都不做持久化处理. 使用 HTTP 协议, 每当有新的请求发送时, 就会有对应的新响应产生.
(3)HTTP 协议相关方法
1)GET : 获取资源
GET 方法用来请求访问已被 URI 识别的资源. 指定的资源经服务器端解析后返回响应内容. 也就是说, 如果请求的资源是文本, 那就保持原样返回; 如果是像 CGI(Common Gateway Interface, 通用网关接口) 那样的程序, 则返回经过执行后的输出结果.
2)POST: 传输实体主体
POST 方法用来传输实体的主体. 虽然用 GET 方法也可以传输实体的主体, 但一般不用 GET 方法进行传输, 而是用 POST 方法. 虽说 POST 的功能与 GET 很相似, 但 POST 的主要目的并不是获取响应的主体内容.
3)PUT: 传输文件
PUT 方法用来传输文件. 就像 FTP 协议的文件上传一样, 要求在请求报文的主体中包含文件内容, 然后保存到请求 URI 指定的位置. 但是, 鉴于 HTTP/1.1 的 PUT 方法自身不带验证机制, 任何人都可以上传文件 , 存在安全性问题, 因此一般的 web 网站不使用该方法. 若配合 Web 应用程序的验证机制, 或架构设计采用 REST(REpresentational State Transfer, 表征状态转移) 标准的同类 Web 网站, 就可能会开放使用 PUT 方法.
4)HEAD: 获得报文首部
HEAD 方法和 GET 方法一样, 只是不返回报文主体部分. 用于确认 URI 的有效性及资源更新的日期时间等.
5)DELETE: 删除文件
DELETE 方法用来删除文件, 是与 PUT 相反的方法. DELETE 方法按请求 URI 删除指定的资源. 跟 put 方法一样, HTTP/1.1 的 DELETE 方法自身不带验证机制.
6)OPTIONS: 询问支持的方法
OPTIONS 方法用来查询针对请求 URI 指定的资源支持的方法.
7)TRACE: 追踪路径
TRACE 方法是让 Web 服务器端将之前的请求通信环回给客户端的方法.
8)CONNECT: 要求用隧道协议连接代理
CONNECT 方法要求在与代理服务器通信时建立隧道, 实现用隧道协议进行 TCP 通信. 主要使用 SSL(Secure Sockets Layer, 安全套接层) 和 TLS(Transport Layer Security, 传输层安全) 协议把通信内容加 密后经网络隧道传输.
(4)持久连接
HTTP 协议的初始版本中, 每进行一次 HTTP 通信就要断开一次 TCP 连接. 但是当请求资源变多的时候多的时候, 会造成资源浪费. 为了解决这一问题, 引入了持久连接. 持久连接的特点是, 只要任意一端没有明确提出断开连接, 则保持 TCP 连接状态. 持久连接的好处在于减少了 TCP 连接的重复建立和断开所造成的额外开销, 减轻了服务器端的负载. 另外, 减少开销的那部分时间, 使 HTTP 请求和响应能够更早地结束, 这样 Web 页面的显示速度也就相应提高了.
(5). 管线化
持久连接使得多数请求以管线化(pipelining) 方式发送成为可能. 从前发送请求后需等待并收到响应, 才能发送下一个请求. 管线化技术出现后, 不用等待响应亦可直接发送下一个请求. 这样就能够做到同时并行发送多个请求, 而不需要一个接一个地等待响应了.
(6)cookie 技术
因为 HTTP 是无状态的, 为了保存一些信息, 引入了 cookie.Cookie 技术通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态. Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie 的首部字段信息, 通知客户端保存 Cookie. 当下次客户端再往该服务器发送请求时, 客户端会自动在请求报文中加入 Cookie 值后发送出去. 服务器端发现客户端发送过来的 Cookie 后, 会去检查究竟是从哪一个客户端发来的连接请求, 然后对比服务器上的记录, 最后得
到之前的状态信息.
(7)发送多种数据的多部分对象集合
MIME(Multipurpose Internet Mail Extensions, 多用途因特网邮件扩展) 机制, 它允许邮件处理文本, 图片, 视频等多个不同类型的数据. 在 HTTP 报文中使用多部分对象集合时, 需要在首部字段里加上 Content-type.
三, HTTP 状态码
参见: https://blog.csdn.net/striveb/article/details/84070336
四, 通信数据转发程序: 代理, 网关, 隧道
当一台虚拟主机上寄存了多个不同主机名和域名的 Web 网站时, 在发送 HTTP 请求时, 必须在 Host 首部内完整指定主机名或域名的 URI. 否则两个不同的域名通过 DNS 解析后, 会得到相同的 IP, 因为它们位于同一个虚拟主机上.
在 HTTP 通信时, 除了客户端和服务器, 还有涉及到一些其他用于通信数据转发的应用程序, 如: 代理, 网关, 隧道等. 它们可以将请求转发给通信线路上的下一站服务器, 并且接收从那台服务器发送的响应再转发给客户端. 接下来就说说这三个程序.
代理:
具有转发功能, 介于服务器和客户端直接, 接收由客户端发送的请求并转发给服务器, 同时也接收服务器返回的响应并转发给客户端.
代理服务器主要就是接收客户端发送的请求后转发给其他服务器. 代理不改变请求 URI, 会直接发送给前方持有资源的目标服务器. 持有资源实体的服务器被称为源服务器. 从源服务器返回的响应经过代理服务器再传给客户端.
在 HTTP 通信过程中, 可级联多台代理服务器. 请求和响应的转发会经过数台类似锁链一样连接过来的代理服务器. 转发时, 需要附加 Via 首部字段以标记出经过的主机信息. 代理服务器利用缓存技术减少网络带宽的流量, 组织内部针对特定网站的访问控制, 以获取访问日志为主要目的等等.
代理有两种基准分类: 1. 是否使用缓存; 2. 是否会修改报文.
缓存代理: 预先将资源的副本 (缓存) 保存在代理服务器上. 当代理再次接收到对相同资源的请求时, 就可以不从源服务器那里获取资源, 而是将当前缓存的资源作为响应返回.
透明代理: 转发请求或响应时, 不对报文做任何加工即为透明代理. 反之, 对报文内容进行加工的代理被称为非透明代理.
网关:
转发其他服务器通信数据的服务器, 接收从客户端发送来的请求时, 对请求进行处理. 其实就是相当于具有处理请求能力的服务器.
网关能使通信线路上的服务器提供非 HTTP 协议服务. 利用网关能提高通信的安全性, 因为可以在客户端与网关之间的通信线路上加密以确保连接的安全. 比如: 网关可以连接数据库, 使用 SQL 语句查询数据.
隧道(相当于是一个确保安全的介质):
在相隔甚远的客户端和服务器两者之间进行中转, 并保持双方通信连接的应用程序. 隧道可按要求建立起一条与其他服务器的通信线路, 然后使用 SSL 等加密手段进行通信, 目的是确保客户端能与服务器进行安全的通信.
隧道本身不会解析 HTTP 请求, 即会保持请求的原样, 其实就是相当于一个介质, 会在通信双方断开连接时结束.
来源: http://www.bubuko.com/infodetail-3324816.html