一、前言

复习网络协议中心常识，进一步夯实根底，为后边 参与物联网、音视频、直播等领域的项目做必定的常识储备。

关于HTTP我们都不陌生，但发起HTTP恳求的进程都发生了什么呢？

二、运用层常见协议

超文本传输协议：HTTP、HTTPS 文件传输：FTP 电子邮件：SMTP、POP3、IMAP 动态主机装备：DHCP 域名体系：DNS

2.1. 域名（Domain Name）

因为IP地址不方便记忆，并且不能表达组织的称号和性质，人们规划出了域名（比方baidu.com）。但实际上，为了能够访问到详细的主机，终究仍是得知道方针主机的IP地址。

为什么不直接用域名？ IP地址固定4个字节，域名随随便便都至少10几个字节，这无疑会增加路由器的担负，浪费流量。

依据等级不同，域名能够分为：

• 尖端域名（Top-level Domain，简称TLD。例，*www.baidu.com*）
• 二级域名（例，graph.baidu.com）
• 三级域名（例，**）
• …

2.1.1. 尖端域名的分类

• 通用尖端域名（General Top-level Domain，简称gTLD）

  • .com（公司），net（网络结构），.org（组织结构，公益性居多），.edu（教育），.gov（政府部门），.int（国际组织）等

• 国家及区域尖端域名（Country Code Top-level Domain，简称ccTLD）

  • .cn（我国），.jp（日本），.uk（英国）

• 新通用尖端域名（New Generic Top-level Domain，简称New gTLD）

  • .vip，.xyz，.top，.club，.shop等

2.1.2. 二级域名

二级域名是指尖端域名之下的域名。

• 在通用尖端域名下，它一般指域名注册人的称号，例如google，baidu，microsoft等
• 在国家及区域尖端域名下，它一般指注册类别的，例如com，edu，gov，net等

例如baidu.com，其实完整的写法是www.baidu.com.，终究是有一个.的，这个点就代表根服务器，DNS解析的时分会主动加上去。

2.2. DNS（Domain Name System）

DNS英文译为：域名体系。

利用DNS协议，能够将域名（比方baidu.com）解析对应的IP地址（比方220.180.38.120）。

DNS能够根据UDP协议，也能够根据TCP协议，服务器占用53端口。

设备访问一个域名的时分会优先从本地称号服务器查找对应的IP，假如没有找到就会恳求根服务器，一级一级往下找，直到找到对应的域名为止，终究将域名对应的IP回来到设备并在本地服务器做一个缓存。

常用指令：

• ipconfig /displaydns：检查DNS缓存记录
• ipconfig /flushdns：清空DNS缓存记录
• ping 域名：测验指定域名服务器的衔接状况
• nslookup 域名：检查指定域名的IP地址

三、IP地址的分配

IP地址依照分配办法能够分为：静态IP地址、动态IP地址。

3.1. 静态IP地址

静态IP地址是手动设置的。

适用场景：不怎么挪动的台式机（比方校园机房中的台式机），服务器等。

3.2. 动态IP地址（DHCP）

从DHCP服务器主动获取IP地址。

适用场景：移动设备、无线设备等。

DHCP（Dynamic Host Configuration Protocol），动态主机装备协议。

DHCP协议根据UDP协议，客户端是68端口，服务器是67端口。

DHCP服务器会从IP地址池中，挑选一个IP地址“租借”给客户端一段时刻，时刻到期就回收它们。平时家里上网的路由器就能够充任DHCP服务器。

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

1. DISCOVER：发现服务器。

   • 发播送包（源IP是0.0.0.0，方针IP是255.255.255.255，方针MAC是FF:FF:FF:FF:FF:FF）

2. OFFER：供给租约

   • 服务器回来能够租借的IP地址，以及租借期限、子网掩码、网关、DNS等信息

3. REQUEST：挑选IP地址

   • 客户端挑选一个OFFER，发送播送包进行回应

4. ACKNOWLEDGE：确认

   • 被选中的服务器发送ACK数据包给客户端

DHCP服务器能够跨网段分配IP地址么？（DHCP服务器、客户端不在同一个网段）

能够借助DHCP中继署理（DHCP Relay Agent）实现跨网段分配IP地址。

3.2.2. 主动续约

客户端会在租期不足的时分，主意向DHCP服务器发送REQUEST信息恳求续约。

常用指令：

• ipconfig /all：能够看到DHCP相关的详细信息，比方租约过期时刻、DHCP服务器地址等。
• ipconfig /release：开释租约
• ipconfig /renew：重新恳求IP地址、恳求续约（延长租期）

四、HTTP

HTTP（Hyper Text Transfer Protocol），超文本传输协议。是互联网中运用最广泛的运用层协议之一。

规划HTTP开始的目的是：供给一种发布和接纳HTML页面的办法（这也是为什么叫HTTP，因为HTTP开始便是用来传输HTML的），由URI来标识详细的资源。后边用HTTP来传递的数据格局不仅仅是HTML，运用十分广泛。

URL是URI的子级，URI是一致资源标识符，在服务器中是仅有的。URL是一致资源定位符，是为了定位资源方位的。

HTML（Hyper Text Markup Language），超文本符号言语（用标签符号一般文本使其表达超出文本规模的内容）。用来编写网页的。

对比百度百科和维基百科的词条内容，就知道为什么维基百科愈加权威和受欢迎。

4.1. 版别历史

• 1991年，HTTP/0.9

  • 只支撑GET恳求办法获取文本数据（比方HTML文档），且不支撑恳求头、呼应头号，无法向服务器传递太多信息

• 1996年，HTTP/1.0

  • 支撑POST、HEAD等恳求办法，支撑恳求头、呼应头号，支撑更多种数据类型（不再局限于文本数据）
  • 浏览器的每次恳求都需求与服务器建立一个TCP衔接，恳求处理完结后立即断开TCP衔接

• 1997，HTTP/1.1（最经典，运用最广泛的版别）

  • 支撑PUT、DELETE等恳求办法
  • 选用耐久衔接（Connection keep-alive），多个恳求能够共用同一个TCP衔接

• 2015，HTTP/2.0（正在替代1.1）

• 2018，HTTP/3.0（处于草稿阶段）

4.2. 规范

HTTP的规范是由万维网协会（W3C）、互联网工程任务组（IETF）和谐制定，终究发布了一系列的RFC。

RFC（Request For Comments），恳求意见稿。恳求的内容被审阅通往后就会成为HTTP规范。

• HTTP/1.0最早是在1997年的RFC_2068中记录的，该规范在1999年的RFC_2616中已作废，2014年又由RFC_7230系列的RFC替代。
• HTTP/2.0规范于2015年5月以RFC_7540正式发表，替代HTTP/1.1成为HTTP的实现规范

1996年3月，清华大学提交的习惯不同国家和区域中文编码的汉字一致传输规范被IETF经过为RFC_1922，成为我国大陆第一个被认可为RFC文件的提交协议。

经过抓包本地服务器探索恳求进程：

恳求报文和呼应报文格局：

HTTP的恳求头和呼应头格局都是固定的，有必要依照指定格局收发数据，否则就无法正常建立通讯。份额空格、换行、键值对的键（字段名）。

每个字符（16进制）都有对应的ASCII码值：

为什么运用0d0a呢（既有回车又有换行）？首要是为了兼容不同的操作体系，因为有些操作体系0a代表换行，有些操作体系换行的操作符是0d。

4.3. ABNF

ABNF（Augmented BNF），是BNF（Backus-Naur Form，译：巴克斯-瑙尔范式）的修正/增强版。在RFC_5234中标明ABNF用作internet中通讯协议的定义言语。

ABNF是最严谨的HTTP报文格局描绘方法，脱离ABNF议论HTTP报文格局，往往都是不严谨的。

关于HTTP报文格局的定义：

• 旧版：RFC_2616_4.HTTP Message
• 新版：RFC_7230_3.Message Format

ABNF中心规则：

4.3.1. 报文格局

scss
HTTP-message   = start-line
                 *( header-field CRLF )
                 CRLF
                 [ message-body ]
start-line     = request-line / status-line

• start-line：request-line代表恳求报文（恳求行），status-line代表呼应报文（状况行）
• *：0个或多个。2*表明至少2个，3*6表明3到6个
• 每一个header-field后边都有必要加上回车换行符CRLF，header-field全体后边也有必要加上回车换行符CRLF
• ()：组成一个全体
• []：可选（恳求体、呼应体）

4.3.2. request-line、status-line

start-line内部包含了空格，所以在报文格局中没有看到换行符CRLF。

ABNF中的注释格局是：分号(;)+内容，例;这里描绘的是注释内容。

ini
// SP = Space（空格），DIGIT代表数字，详细可参考上面的ABNF中心规则
// 恳求行（例：GET /hello/ HTTP/1.1）
request-line = method SP request-target SP HTTP-version CRLF
// HTTP-version格局（例：HTTP/1.1）
HTTP-version  = HTTP-name "/" DIGIT "." DIGIT
// HTTP-name格局（%x48.54.54.50是HTTP的16进制ASCII码值）
HTTP-name     = %x48.54.54.50 ; "HTTP", case-sensitive
// 状况行（例：HTTP/1.1 200）
status-line = HTTP-version SP status-code SP reason-phrase CRLF
// 状况码由3个数字组成（例：200、300、500等）
status-code    = 3DIGIT
// 状况描绘，能够是Tab、空格、字符或obs文字，*代表是可选项（例：OK）
reason-phrase  = *( HTAB / SP / VCHAR / obs-text )

4.3.3. header-field、message-body

ini
// 恳求头键值对（例：Host: localhost:8080）
header-field   = field-name ":" OWS field-value OWS
// 指定键名
field-name     = token
// 值（可有可无）
field-value    = *( field-content / obs-fold )
// 空格或Tab键（*代表该值可有可无，也便是说有OWS的地方能够没有空格也能够有多个空格）
OWS = *( SP / HTAB )
// 音讯体（只要是字节就能够）
message-body = *OCTET

4.3.4. telnet

运用telnet能够直接面向HTTP报文与服务器交互，能够更明晰、直观的看到恳求报文和呼应报文的内容，也能够查验恳求报文格局的正确与否。

Windows体系用户能够运用Xshell软件，Mac体系用户直接指令装置即可（brew install telnet）。

4.4. URL编码

URL中一旦出现了一些特别字符（比方中文、空格），需求进行编码。在浏览器地址栏输入URL时，是选用UTF-8进行编码。比方https://www.baidu.com/s?wd=你好编码后便是https://www.baidu.com/s?wd=%E4%BD%A0%E5%A5%BD。

4.5. 恳求办法

RFC_7231,section-4: Request methods：描绘了8种恳求办法。

在RFC_5789,section-2: Patch methods文档中描绘了PATCH办法。

所以到目前为止一共有9种HTTP恳求办法。最常用的恳求办法是GET和POST。

• GET：常用于读取的操作，恳求参数直接拼接在URL的后边（浏览器或服务器对URL是有长度约束的，ABNF并没有约束URL长度的阐明）

• POST：常用于添加、修正、删除的操作，恳求参数能够放到恳求体中（没有巨细约束）

• HEAD：恳求得到与GET恳求相同的呼应，但没有呼应体

  • 运用场景举例：在下载一个大文件前，先获取其巨细，再决议是否要下载，以此能够节省带宽资源

• OPTIONS：用于获取目的资源所支撑的通讯选项，比方服务器支撑的恳求办法

  • 运用telnet衔接服务器后输入OPTIONS * HTTP/1.1（*代表所有路径），回来Allow: GET, HEAD, POST, PUT, DELETE, OPTIONS

• PUT：用于对已存在的资源进行全体掩盖（很少运用，因为是直接掩盖数据，所以不太安全）

• DELETE：用于删除指定的资源（很少运用，不安全）

• PATCH：用于对资源进行部分修正（资源不存在，会创立新的资源。很少运用，不安全）

• CONNECT：能够开启一个客户端与所恳求资源之间的双向交流的通道，它能够用来创立地道（tunnel）

  • 能够用来访问选用了SSL（HTTPS）协议的站点

• TRACE：恳求服务器回显其收到的恳求信息（恳求什么内容就呼应什么内容），首要用于HTTP恳求的测验或诊断

4.6. 恳求头字段

头部字段（Header Field）能够分为4种类型：

• 恳求头字段（Request Header Fields）

  • 有关要获取的资源或客户端本身信息的音讯头

• 呼应头字段（Response Header Fields）

  • 有关呼应的补充信息，比方服务器本身（称号和版别等）的音讯头

• 实体头字段（Entity Header Fields）

  • 有关实体主体的更多信息，比方主体长度（Content-Length）或其MIME类型

• 通用头字段（General Header Fields）

  • 一起适用于恳求和呼应音讯，但与音讯主体无关的音讯头，比方时刻（Date）

bash
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9

上面恳求头的接纳类型包含了很多种，每一种运用逗号,离隔，q=0.8是权重的意思，权重值越大，优先级越高（优先回来哪一种类型）。假如不指定q值，默认是1.0（最大值）。

4.7. 呼应头字段

4.8. 状况码（Status Code）

状况码是在RFC_2616,section-10:Status Code Definitions规范中定义的。状况码指示HTTP恳求是否已成功完结。

4.8.1. 状况码分类

状况码分为5类：

• 信息呼应：100~199
• 成功呼应：200~299
• 重定向：300~399
• 客户端过错：400~499
• 服务器过错：500~599

4.8.2. 常见状况码

100（Continue） 恳求的初始化部分现已被服务器收到，并且没有被服务器回绝。客户端应该持续发送剩余的恳求，假如恳求现已完结，就疏忽这个呼应。

运用场景：答应客户端发送带恳求体的恳求前，判别服务器是否乐意接纳恳求（服务器经过恳求头判别）。在某些状况下，假如服务器在不看恳求体就回绝恳求时，客户端就发送恳求体是不恰当的或低效的。

200（OK） 恳求成功

302（Found） 恳求的资源被暂时的移动到了由Location头部指定的URL上。

304（Not Modified） 阐明无需再次传输恳求的内容（也便是说客户端能够运用之前302缓存的内容，服务器只回来呼应头）。

400（Bad Request） 因为语法无效，服务器无法理解该恳求。

401（Unauthorized） 因为缺乏方针资源要求的身份验证凭据。

403（Forbidden） 服务端有才能处理该恳求，但是回绝授权访问。

404（Not Found） 服务器端无法找到所恳求的资源。

405（Method Not Allowed） 服务器禁止了运用当前HTTP办法的恳求（比方应该运用POST恳求而客户端运用的是GET恳求）。

406（Not Acceptable） 服务器端无法供给与Accept-Charset以及Accept-Language指定的值相匹配的呼应。

408（Request Timeout） 服务器想要将没有在运用的衔接关闭（一些服务器会在闲暇衔接上发送此信息，即便在客户端没有发送任何恳求的状况下）。

500（Internal Server Error） 所恳求的服务器遇到意外的状况并阻止其履行恳求。

501（Not Implemented） 恳求的办法不被服务器支撑，因此无法被处理。

服务器有必要支撑的办法（即不会回来这个状况码的办法）只要GET和HEAD。

留意和405的区分：405代表服务器支撑该恳求办法，仅仅客户端运用了过错的恳求办法；而501是服务器不支撑该恳求办法。

502（Bad Gateway） 作为网关或署理角色的服务器，从上游服务器（如tomcat）中接纳到的呼应是无效的。

503（Service Unavailable） 服务器没有处于能够接受恳求的状况。一般形成这种状况的原因是因为服务器停机维护或许已超载。

4.9. form（表单）提交

常用属性：

• action：恳求的URI

• method：恳求办法（只支撑GET和POST）

• enctype：POST恳求时，恳求体的编码办法

  • application/x-www-form-urlencoded，默认值。用&分割参数，用=分割键和值，字符用URL编码办法进行编码
  • multipart/form-data：文件上传时有必要运用这种编码办法

multipart/form-data参考RFC_1521。

恳求头：

Content-Type: multipart/form-data; boundary=xxx

恳求体：

multipart-body := preamble 1*encapsulation
               close-delimiter epilogue
encapsulation := delimiter body-part CRLF
delimiter := "--" boundary CRLF ; taken from Content-Type field.
                                ; There must be no space
                                ; between "--" and boundary.
close-delimiter := "--" boundary "--" CRLF ; Again, no space
   by "--",
preamble := discard-text   ;  to  be  ignored upon receipt.
epilogue := discard-text   ;  to  be  ignored upon receipt.