网络协议六:应用层

  1. 应用层的常见协议
    1. 超文本传输:HTTP、HTTPS
    2. 文件传输:FTP
    3. 电子邮件:SMTP、POP3、IMAP
    4. 动态主机配置:DHCP
    5. 域名系统:DNS

域名(Domain Name)

  1. 由于IP地址不方便记忆,并且不能表达组织的名称和性质,人们设计出了域名(比如baidu.com)
    1. 但实际上,为了能够访问到具体的主机,最终还是得知道目标主机的IP地址
    2. 域名申请注册:https://wanwang.aliyun.com/
  2. 那干脆全程直接用域名,不用IP地址?
    1. IP地址固定4个字节,域名随随便便都至少10几个字节,这无疑会增加路由器的负担,浪费流量
  3. 根据级别不同,域名可以分为
    1. 顶级域名(Top-level Domain,简称TLD)
    2. 二级域名
    3. 三级域名

顶级域名的分类

  1. 通用顶级域名(General Top-level Domain,简称gTLD)
    1. .com(公司),.net(网络机构),.org(组织机构),.edu(教育)
    2. .gov(政府部门),.int(国际组织)等
  2. 国家及地区顶级域名(Country Code Top-level Domain,简称ccTLD)
    1. .cn(中国)、.jp(日本)、.uk(英国)
  3. 新通用顶级域名(New Generic Top-level Domain,简称:New gTLD)
    1. .vip、.xyz、.top、.club、.shop等

二级域名

  1. 二级域名是指顶级域名之下的域名
    1. 在通用顶级域名下,它一般指域名注册人的名称,例如google、baidu、microsoft等
    2. 在国家及地区顶级域名下,它一般指注册类别的,例如com、edu、gov、net等
    3. 举例:baidu.com,其中.com为顶级域名,baidu为二级域名

DNS

  1. DNS的全称是:Domain Name System,译为:域名系统
    1. 利用DNS协议,可以将域名(比如baidu.com)解析成对应的IP地址(比如220.181.38.148)
    2. DNS可以基于UDP协议,也可以基于TCP协议,服务器占用53端口
    3. DNS也是一个应用层的网络协议,跟HTTP一样
    4. 比如:在浏览器输入http://www.baidu.com回车,它首先要通过DNS协议发送DNS数据包DNS服务器去访问获取到百度的IP地址,然后才能通过IP地址进行访问百度的服务器
    5. DNS有缓存,下次再请求时就不需要进行访问了
  2. DNS服务器
    1. 客户端首先会访问最近的一台DNS服务器(也就是客户端自己配置的DNS服务器)
    2. 所有的DNS服务器都记录了DNS根域名服务器的IP地址
    3. 上级DNS服务器记录了下一级DNS服务器的IP地址
    4. 全球一共13台IPv4的DNS根域名服务器、25台IPv6的DNS根域名服务器
  3. DNS常用命令
    1. ipconfig /displaydns:查看DNS缓存记录
    2. ipconfig /flushdns:清空DNS缓存记录
    3. ping 域名
    4. nslookup 域名

    图1

DHCP

1.IP地址的分配

  1. IP地址按照分配方式,可以分为:静态IP地址、动态IP地址
    1. 静态IP地址
      1. 手动设置
      2. 适用场景:不怎么挪动的台式机(比如学校机房中的台式机)、服务器等
  2. 动态IP地址
    1. DHCP服务器自动获取IP地址
    2. 适用场景:移动设备、无线设备等

2.DHCP

  1. DHCP(Dynamic Host Configuration Protocol),译为:动态主机配置协议
    1. DHCP协议基于UDP协议,客户端是68端口,服务器是67端口
    2. DHCP也是个协议,也有对应的服务器
  2. DHCP服务器会从IP地址池中,挑选一个IP地址“出租“给客户端一段时间,时间到期就回收它们
    1. 平时家里上网的路由器就可以充当DHCP服务器

3.分配IP地址的4个阶段

  1. DISCOVER:发现服务器
    1. 发广播包(源IP是0.0.0.0,目标IP是255.255.255.255,目标MAC是FF:FF:FF:FF:FF:FF)
    2. 发广播就意味着当前主机可以没有IP地址,直接广播发出去
    3. 目的就是查找附近有哪些DHCP服务器可以使用
  2. OFFER:提供租约
    1. 找到DHCP服务器之后,服务器返回可以租用的IP地址,以及租用期限、子网掩码、网关、DNS等信息
    2. 注意:这里可能会有多个服务器提供租约
  3. REQUEST:选择IP地址
    1. 客户端选择一个OFFER,发送广播包进行回应
  4. ACKNOWLEDGE:确认
    1. 被选中的服务器发送ACK数据包给客户端
    2. 至此,IP地址分配完毕

图1

4.细节

  1. DHCP服务器可以跨网段分配IP地址么?(DHCP服务器、客户端不在同一个网段)
    1. 可以借助DHCP中继代理(DHCP Relay Agent)实现跨网段分配IP地址
  2. 自动续约
    1. 客户端会在租期不足的时候,自动向DHCP服务器发送REQUEST信息申请续约
  3. 常用命令
    1. ipconfig /all:可以看到DHCP相关的详细信息,比如租约过期时间、DHCP服务器地址等
    2. ipconfig /release:释放租约
    3. ipconfig /renew:重新申请IP地址、申请续约(延长租期)

HTTP

  1. HTTP(Hyper Text Transfer Protocol),译为超文本传输协议
    1. 是互联网中应用最广泛的应用层协议之一
    2. 设计HTTP最初的目的是:提供一种发布和接收HTML页面的方法,由URI(URI包括URL)来标识具体的资源
    3. 后面用HTTP来传递的数据格式不仅仅是HTML,应用非常广泛
  2. 版本
    1. 1991年,HTTP/0.9
      1. 只支持GET请求方法获取文本数据(比如HTML文档),且不支持请求头、响应头等,无法向服务器传递太多信息
    2. 1996年,HTTP/1.0
      1. 支持POST、HEAD等请求方法,支持请求头、响应头等,支持更多种数据类型(不再局限于文本数据)
      2. 浏览器的每次请求都需要与服务器建立一个TCP连接,请求处理完成后立即断开TCP连接
    3. 1997年,HTTP/1.1(最经典、使用最广泛的版本)
      1. 支持PUT、DELETE等请求方法
      2. 采用持久连接(Connection: keep-alive),多个请求可以共用同一个TCP连接
    4. 2015年,HTTP/2.0
    5. 2018年,HTTP/3.0
  3. 标准
    1. HTTP的标准
      1. 由万维网协会(W3C)、互联网工程任务组(IETF)协调制定,最终发布了一系列的RFC
    2. RFC(Request For Comments,可以译为:请求意见稿)
      1. HTTP/1.1最早是在1997年的RFC 2068中记录的
        1. 该规范在1999年的RFC 2616中已作废
        2. 2014年又由RFC 7230系列的RFC取代
      2. HTTP/2标准于2015年5月以RFC 7540正式发表,取代HTTP/1.1成为HTTP的实现标准
    3. 中国的RFC
      1. 1996年3月,清华大学提交的适应不同国家和地区中文编码的汉字统一传输标准被IETF通过为RFC 1922
      2. 成为中国大陆第一个被认可为RFC文件的提交协议
  4. 报文格式 图1

    图1

    1. 首部行:就是请求头、响应头,都是key(首部字段名)、value(值)键值对
    2. 实体主题: 就是请求体、响应体
    3. get请求没有请求体

ABNF(Augmented BNF)

  1. ABNF
    1. 是BNF(Backus-Naur Form,译为:巴科斯-瑙尔范式)的修改、增强版
    2. 在RFC 5234中表明:ABNF用作internet中通信协议的定义语言
    3. ABNF是最严谨的HTTP报文格式描述形式,脱离ABNF谈论HTTP报文格式,往往都是片面、不严谨的
    4. 即ABNF就是规定HTTP报文的一种语言
  2. 关于HTTP报文格式的定义
    1. RFC 2616 4.HTTP Message(旧)
    2. RFC 7230 3.Message Format(新)
  3. 报文格式(Message Format)整体

     HTTP-message   = start-line
                       *( header-field CRLF )
                       CRLF
                       [ message-body ]
                          
     start-line = request-line / status-line
    
    1. 符号表达意思

       /       任选一个
       *       0个或多个。2*表示至少2个,3*6表示3到6个
       ()      组成一个整体
       []      可选(可有可无)
       CRLF    回车换行
      
  4. request-line、status-line
    1. request-line
      1. request-line = method SP request-target SP HTTP-version CRLF
      2. HTTP-version = HTTP-name “/” DIGIT “.” DIGIT
      3. HTTP-name = %x48.54.54.50 ; HTTP
        1. 分号(;)表示注释,%x48.54.54.50对应的ASCII为HTTP
      4. 举例: GET /hello/ HTTP/1.1
    2. status-line
      1. status-line = HTTP-version SP status-code SP reason-phrase CRLF
      2. status-code = 3DIGIT
      3. reason-phrase = *( HTAB / SP / VCHAR / obs-text )
      4. 举例:HTTP/1.1 200 、 HTTP/1.1 200 OK
  5. header-field 、 message-body
    1. header-field
      1. header-field = field-name “:” OWS field-value OWS
      2. field-name = token
      3. field-value = *(field-content/obs-fold)
      4. OWS = *(SP/HTAB)
    2. message-body
      1. message-body = *OCTET
  6. ABNF核心规则

    图1

HTTP请求

URL的编码

  1. URL中一旦出现了一些特殊字符(比如中文、空格),需要进行编码
    1. 在浏览器地址栏输入URL时,是采用UTF-8进行编码S
  2. 比如
    1. 编码前:https://www.baidu.com/s?wd=百度
    2. 编码后:https://www.baidu.com/s?wd=%E5%8D%8E%E4%B8%BA

Xshell + telnet

  1. 安装一个Xshell(安全终端模拟软件),在Xhell中使用telnet(只有windows版本,Mac不需要,直接可以使用telnet)
    1. 可以直接面向HTTP报文与服务器交互
    2. 可以更清晰、直观地看到请求报文、响应报文的内容
    3. 可以检验请求报文格式的正确与否
  2. 使用
    1. 连接服务器:telnet localhost 8080
    2. 发送HTTP报文

      图1

请求方法

  1. RFC 7231, section 4: Request methods:描述了8种请求方法
    1. GET、HEAD、POST、PUT、DELETE、CONNECT、OPTIONS、TRACE
  2. RFC 5789, section 2: Patch method:描述了PATCH方法
  3. GET:常用于读取的操作,请求参数直接拼接在URL的后面(浏览器对URL是有长度限制的)
  4. POST:常用于添加、修改、删除的操作,请求参数可以放到请求体中(没有大小限制)
  5. HEAD:请求得到与GET请求相同的响应,但没有响应体
    1. 使用场景举例:在下载一个大文件前,先获取其大小,再决定是否要下载。以此可以节约带宽资源
  6. OPTIONS:用于获取目的资源所支持的通信选项,比如服务器支持的请求方法
    1. OPTIONS * HTTP/1.1
  7. PUT:用于对已存在的资源进行整体覆盖
  8. PATCH:用于对资源进行部分修改(资源不存在,会创建新的资源)
  9. DELETE:用于删除指定的资源
  10. TRACE:请求服务器回显其收到的请求信息,主要用于HTTP请求的测试或诊断
  11. CONNECT:可以开启一个客户端与所请求资源之间的双向沟通的通道,它可以用来创建隧道(tunnel)
    1. 可以用来访问采用了 SSL (HTTPS) 协议的站点

头部字段(Header Field)

  1. 头部字段可以分为4种类型
    1. 请求头字段(Request Header Fields)
      1. 有关要获取的资源或客户端本身信息的消息头
    2. 响应头字段(Response Header Fields)
      1. 有关响应的补充信息,比如服务器本身(名称和版本等)的消息头
    3. 实体头字段(Entity Header Fields)
      1. 有关实体主体的更多信息,比如主体长度(Content-Length)或其MIME类型
    4. 通用头字段(General Header Fields)
      1. 同时适用于请求和响应消息,但与消息主体无关的消息头
  2. 请求头字段

    图1

    1. q值越大,表示优先级越高
    2. 如果不指定q值,默认是1.0(1.0是最大值)
  3. 响应头字段 图1

状态码(Status Code)

  1. RFC 2616 10.Status Code Definitions规范中定义
    1. 状态码指示HTTP请求是否已成功完成
  2. 状态码可以分为5类
    1. 信息响应:100~199
    2. 成功响应:200~299
    3. 重定向:300~399
    4. 客户端错误:400~499
    5. 服务器错误 :500~599
  3. 常见状态码

     100 Continue
         1. 请求的初始部分已经被服务器收到,并且没有被服务器拒绝。客户端应该继续发送剩余的请求,如果请求已经完成,就忽略这个响应
         2. 允许客户端发送带请求体的请求前,判断服务器是否愿意接收请求(服务器通过请求头判断)
         3. 在某些情况下,如果服务器在不看请求体就拒绝请求时,客户端就发送请求体是不恰当的或低效的
     200 OK:请求成功
     302 Found:请求的资源被暂时的移动到了由Location头部指定的URL上
     304 Not Modified:说明无需再次传输请求的内容,也就是说可以使用缓存的内容
     400 Bad Request:由于语法无效,服务器无法理解该请求
     401 Unauthorized:由于缺乏目标资源要求的身份验证凭证
     403 Forbidden:服务器端有能力处理该请求,但是拒绝授权访问
     404 Not Found:服务器端无法找到所请求的资源
     405 Method Not Allowed:服务器禁止了使用当前HTTP方法的请求
     406 Not Acceptable:服务器端无法提供与Accept-Charset以及Accept-Language指定的值相匹配的响应
     408 Request Timeout:服务器想要将没有在使用的连接关闭
         1. 一些服务器会在空闲连接上发送此信息,即便是在客户端没有发送任何请求的情况下
     500 Internal Server Error:所请求的服务器遇到意外的情况并阻止其执行请求
         1. 服务器必须支持的方法(即不会返回这个状态码的方法)只有 GET 和 HEAD
     502 Bad Gateway:作为网关或代理角色的服务器,从上游服务器(如tomcat)中接收到的响应是无效的
     503 Service Unavailable:服务器尚未处于可以接受请求的状态
         1. 通常造成这种情况的原因是由于服务器停机维护或者已超载
    

form提交(web的form标签使用)

  1. 常用属性
    1. action:请求的URI
    2. method:请求方法(GET、POST)
    3. enctype:POST请求时,请求体的编码方式
      1. application/x-www-form-urlencoded(默认值)
        1. 用&分隔参数,用=分隔键和值,字符用URL编码方式进行编码
      2. multipart/form-data
        1. 文件上传时必须使用这种编码方式
  2. multipart/form-data;
    1. 参考RFC 1521
    2. 可以参看请求的格式

常用的请求头与响应头字段分析

  1. 跨域Origin(请求头字段)与Access-Control-Allow-Origin(响应头字段) 略
  2. Cookie与Set-Cookie字段
    1. Cookie
      1. 在客户端(浏览器)存储一些数据,存储到本地磁盘(硬盘)
      2. 服务器通过Set-Cookie响应头字段将数据交给浏览器去存储到Cookie中
      3. 默认关闭浏览器会删除本地的Cookie,但是可以设置删除时间
    2. Session
      1. 在服务器存储一些数据,存储到内存中
      2. 存储完会自动生成一个JSSESSIONID,存储在Set-Cookie中
    3. Set-Cookie:
      1. 就是服务器返回给浏览器的响应头字段,希望浏览器存储在自己Cookie中的数据
      2. 一旦服务器通过Session存储了客户端传递过来的数据,就会生成一些数据(JSSESSIONID),自动通过Set-Cookie返回给客户端

代理

  1. 代理服务器(Proxy Server)
    1. 正常情况下客服端直接跟服务器进行交互;但是有些情况,客户端与服务器交互时要先通过一个中间服务器,去找对应的目的方。这个中间服务器就是代理服务器
    2. 代理的作用:
      1. 如果A访问C,但是无法访问到;但是B可以访问C,同时A也可以访问B,那么我就就可以通过A-B-C实现对C的访问
    3. 特点
      1. 本身不生产内容
      2. 处于中间位置转发上下游的请求和响应
        1. 面向下游的客户端:它是服务器
        2. 面向上游的服务器:它是客户端
  2. 正向代理、反向代理
    1. 正向代理:代理的对象是客户端
    2. 反向代理:代理的对象是服务器
    3. 正向代理作用
      1. 隐藏客户端身份
      2. 绕过防火墙(突破访问限制)
      3. Internet访问控制
      4. 数据过滤
      5. 一些免费的正向代理
        1. https://ip.jiangxianli.com/
        2. https://www.kuaidaili.com/free/inha/
    4. 反向代理作用
      1. 隐藏服务器身份
      2. 安全防护
      3. 负载均衡

图1

抓包工具的原理

  1. Fiddler、Charles等抓包工具的原理:在客户端启动了正向代理服务
  2. 需要注意的是
    1. Wireshark的原理是:通过底层驱动,拦截网卡上流过的数据

代理服务器-相关的头部字段

  1. Via:追加经过的每一台代理服务器的主机名(或域名)
  2. X-Forwarded-For:追加请求方的IP地址
  3. X-Real-IP:客户端的真实IP地址

图1

CDN

  1. CDN(Content Delivery Network或Content Distribution Network),译为:内容分发网络
    1. 利用最靠近每位用户的服务器
    2. 更快更可靠地将音乐、图片、视频等资源文件(一般是静态资源)传递给用户
  2. CDN运营商在全国、乃至全球的各个大枢纽城市都建立了机房
    1. 部署了大量拥有高存储高带宽的节点,构建了一个跨运营商、跨地域的专用网络
  3. 内容所有者向CDN运营商支付费用,CDN将其内容交付给最终用户

    图1

  4. CDN的使用举例
    1. 使用cdn引入jquery
     <script src="https://cdn.bootcdn.net/ajax/libs/jquery/3.5.1/jquery.min.js"></script>
     <script>
         $(document.body).css('background','#f00')
     </script>
    
Table of Contents