应用层 - 常见协议、域名、DNS、DHCP、HTTP、form提交、正向代理反向代理、CDN

应用层 - 常见协议、域名、DNS、DHCP、HTTP、form提交、正向代理反向代理、CDN

2024-10-31 20:53

应用层的常见协议：

超文本传输：HTTP、HTTPS

文件传输：FTP

电子邮件：SMTP、POP3、IMAP

动态主机配置：DHCP

域名系统：DNS

域名（Domain Name）

由于IP地址不方便记忆，并且不能表达组织的名称和性质，人们设计出了域名（比如baidu.com）

但实际上，为了能够访问具体的主机，最终还是得知道目标主机的IP地址

域名申请注册：

那干脆全程直接用域名，不用IP地址？

IP地址固定4个字节，域名随随便便都至少10几个字节，这无疑会增加路由器的负担，浪费流量

根据级别不同，域名可以分为

顶级域名
二级域名
三级域名
……

域名 —— 顶级域名的分类

通用顶级域名（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等

域名 —— 二级域名

二级域名是指顶级域名之下的域名

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

DNS

DNS的全称是： Domain Name System，译为：域名系统

利用DNS协议，可以将域名（比如baidu.com）解析成对应的IP地址（比如220.181.38.148）
DNS可以基于UDP协议，也可以基于TCP协议，服务器占用53端口

DNS —— 服务器

客户端首先会访问最近的一台服务器（也就是客户端自己配置的DNS服务器）
所有的DNS服务器都记录了DNS根域名服务器的IP地址
上级DNS服务器记录了下一级DNS服务器的IP地址
全球一共13台IPv4的DNS根域名服务器，25台IPv6的DNS根域名服务器

DNS常用命令

ipconfig /displaydns: 查看DNS缓存记录
ipconfig /flushdns: 清空DNS缓存记录
ping 域名
nslookup 域名

IP地址的分配

IP地址按照分配方式，可以分为：静态IP地址、动态IP地址

静态IP地址

手动设置
适用场景：不怎么挪动的台式机（比如学校机房中的台式机）、服务器等。

动态IP地址

从DHCP服务器自动获取IP地址
适用场景：移动设备、无线设备等。

DHCP

动态主机配置协议（Dynamic Host Configuration Protocol）

DHCP协议基于UDP协议，客户端是68端口、服务器是67端口

DHCP服务器会从IP地址池中，挑选一个IP地址“出租”给客户端一段时间，时间到期就回收它们

平时家里上网的路由器就可以充当DHCP服务器

DHCP —— 分配IP地址的4个阶段

DISCOVER：发现服务器

发广播包（源IP是0.0.0.0，目标IP是255.255.255.255，目标MAC是FF:FF:FF:FF:FF:FF）

OFFER：提供租约

服务器返回可以租用的IP地址，以及租用期限、子网掩码、网关、DNS等信息

（注意：这里可能会有多个服务器提供租约）

REQUEST：选择IP地址

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

ACKNOWLEDGE：确认

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

至此，IP地址分配完毕

DHCP —— 4个阶段

DHCP —— 细节

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

可以借助DHCP中继代理（DHCP Relay Agent）实现跨网段分配IP地址

自动续约

客户端会在租期不足的时候，自动向DHCP服务器发送REQUEST信息申请续约

常用命令

ipconfig /all:可以看到DHCP相关的详细信息，比如租约过期时间、DHCP服务器地址等

ipconfig /release:释放租约

ipconfig /renew:重新申请IP地址、申请续约（延长租期）

HTTP

HTTP ：超文本传输协议（Hyper Text Transfer Protocol）

是互联网中应用最广泛的应用层协议之一
设计HTTP最初的目的是：提供一种发布和接收HTML页面的方法，由URI来标识具体的资源（也就是能让用户浏览网页）（URI包括了URL）

html/login.html URI不能全网唯一，只能在局部某些条件下唯一

http://localhost:8080/hello/html/login.html URL能办到全网唯一

后面用HTTP来传递的数据格式不仅仅是HTML，应用非常广泛

HTML（Hyper Text Markup Lauguage）：超文本标记语言

用以编写网页

维基百科

HTTP版本

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
2018年， HTTP/3.0

HTTP标准

HTTP的标准

由万维网协会（W3C）、互联网工程任务组（IETF）协调制定，最终发布了一系列的RFC

（Request For Comments，可译为：请求意见稿）

HTTP/1.1最早是在1997年的中记录的

该规范在1999年的中已作废

2014年又由系列的RFC取代

HTTP/2标准于2015年5月以正式发表，取代HTTP/1.1成为HTTP的实现标准

中国的RFC

1996年，清华大学提交的适应不同国家和地区中文编码的汉字统一传输标准被IETF通过

成为中国大陆第一个被认可的RFC文件的提交协议

报文格式

在抓包工具中找一个HTTP ，然后追踪流

post请求（后面才有实体主体（请求体））

get请求没有请求体

ABNF

ABNF（Augmented BNF）

是BNF(Backus-Naur Form)的修改、增强版
在中表明：ABNF用作internet中通信协议的定义语言
ABNF是最严谨的HTTP报文格式描述形式，脱离ABNF谈论HTTP报文格式，往往都是片面的、不严谨的

关于HTTP报文格式的定义

（旧）
（新）

ABNF —— 核心规则

报文格式 —— 整体

报文格式 -- request-line、status-line

request-line = method SP request-target SP HTTP-version CRLF
HTTP-version = HTTP-name "/" DIGIT "." DIGIT
HTTP-name = %x48.54.54.50 ; HTTP

GET /hello/ HTTP/1.1

status-line = HTTP-version SP status-code SP reason-phrase CRLF
status-code = 3DIGIT
reason-phrase = *( HTAB / SP / VCHAR / obs-text )

HTTP/1.1 200

HTTP/1.1 200 OK

报文格式 -- header-filed、message-body

header-field = field-name ":" OWS field-value OWS
field-name = token
field-value = *( field-content / obs-fold)

OWS = *( SP / HTAB)

message-body = *OCTET

(OWS包括了空格，也可以是Tab键)

URL的编码

URL一旦出现了一些特殊字符（比如中文、空格），需要进行

在浏览器地址栏输入URL时，是采用UTF-8进行编码

比如:
编码前：
编码后：

Xshell + telent

安装一个（安全终端模拟软件），在Xshell中使用telnet

可以直接面向HTTP报文与服务器交互
可以更清晰、直观地看到请求报文、响应报文的内容
可以检验请求报文格式的正确与否

请求方法

RFC 7231，section 4: Request methods:描述了8种请求方法：

GET HESD POST PUT DELETE ConNECT OPTION TRACE

：描述了PATCH方法
GET：常用于读取的操作，请求参数直接拼接在URL的后面（浏览器对URL是有长度限制的）
POST：常用于添加、修改、删除的操作，请求参数可以放到请求体中（没有大小限制）（请求参数也可以直接放在URL后面）
HEAD：请求得到与GET请求相同的响应，但没有响应体（相当于拿到了GET请求的上半部分）

适用场景举例：在下载一个大文件前，先获取其大小，再决定是否要下载。以此可以节约宽带资源

OPTION：用于获取目的资源所支持的通信选项，比如服务器支持的请求方法

OPTION *HTTP/1.1

PUT：用于对已存在的资源进行整体覆盖
PATCH：用于对资源进行部分修改（资源不存在，会创建新的资源）
DELETE：用于删除指定的资源
TRACE：请求服务器回显其他收到的请求信息，主要用于HTTP请求的测试或诊断
CONNECT：可以开启一个客户端与所请求资源之间的双向沟通的通道，它可以用来创建隧道（tunnel）

可以用来访问采用了SSL（HTTPS）协议的站点

头部字段（Heade Field）

头部字段可以分为4种类型

请求头字段（Request Header Fields）

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

响应头字段（Response Header Fields）

有关响应的补充信息，比如服务器本身（名称和版本等）的消息头

实体头字段（Entity Header Fields）

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

通用头字段（General Header Fields）

同时适用于请求和响应消息，但与消息主体无关的消息头

请求头字段

（Range:可用于多线程断点下载，开多个线程，每个线程下载不同的部分，多个线程同时进行，如果突然断网，客户端写代码记录每一段下载到哪了，联网后就可以重断网处开始下载。

Connection:keep-alive:采用持久连接）

响应头字段

（Content-Disposition：没有设置这个的话，就直接将文件内容显示在网页上，有了这个服务器就会告诉客户端这是个文件数据，需要下载）

Range / Acces-Control-Allow-Origin：用于前后端分离（跨域问题，而跨域问题又受到同源策略的影响）

同源策略

浏览器有个同源策略 (Same-Origin Policy)

它规定了：默认情况下，AJAX请求只能发给同源的URL
同源是指3个相同：协议、域名（IP）、端口

img、script、link、iframe、video、audio 等标签不受同源策略的约束

（浏览器页面的来源是localhost:63342,如果这个页面想发个异步请求过去的话，只能访问http://localhost:63342这台服务器，现在变成了想请求http://localhost:8080，很明显端口号不一样，所以不同源，没办法发请求）

跨域资源共享

解决AJAX跨域请求的常用方法

CROS（Cross-Origin Resource Sharing），跨域资源共享

CROS的实现需要客户端和服务器同时支持

客户端

所有的浏览器都支持

服务器

需要返回相应的响应头（比如Acces-Control-Allow-Origin）

告知浏览器这是一个允许跨域访问的请求

cookie / Set-cookie

（没有登入就去访问已经登入的页面，服务器就会返回一个302，重定向到登入页面，登入成功才能访问到数据）

有另一种情况：

这3次是独立的，因为是同一台服务器，如果进行了第二步，服务器就记录登入的用户名和密码，进行第3步的时候就可以登入进去了，但是，用户名和密码是一直在服务器中记录着的，如果另一个用户再访问这个localhost:8080/xx/user，那就也可以访问了，那就不安全了

那么，服务器要区分请求是不是来源于同一台浏览器

cookie ：在客户端（浏览器）存储一些数据，存储到本地磁盘（硬盘），服务器可以返回cookie交给客户端去存储
Session：在服务器存储一些数据，存储到内存中

（会话跟踪技术）

如果用户名密码错误，就返回登入失败

登入成功

就比如网上购物，可以存储购物车的信息

当然， shopid也可以放数据库里面

淘宝打开小程序，或者直接打开网页，或者是打开APP都可以看到添加至购物车的商品，那么，购物车的商品肯定是放在数据库中的

在小程序上或网页、APP上看不到数据，那么是存在session里面的。

补充：

会话跟踪

HTTP是一种“无状态”（stateless）的协议

每次客户端访问网页时，客户端都会打开与Web服务器的单独连接
并且服务器不会自动保留之前客户端请求的任何记录
所以服务器无法识别多个请求是否来自同一个客户端

在很多应用场景中，都有以下需求

服务器能够识别出多个请求是否来自同一个客户端
在来自同一个客户端的多个请求之间共享数据

以上需求可以使用会话跟踪技术来完成，在Java中，实现会话跟踪的常用方案是：

Session
cookie

cookie

cookie是直接存储在浏览器本地的一串数据

使用document.cookie访问cookie
修改cookie时，只会修改其中提到的cookie
name = value必须被编码（encodeURIComponent）
一个cookie最大为4kb，每个网站最多有20+个左右的cookie（具体取决于浏览器）

Windows中的Chrome浏览器的cookie存放位置

C:User用户名AppDataLocalGoogleChromeUser DataDefaultcookies
使用SQLite数据库进行存储

cookie的有效期

如果没有设置cookie的过期时间，则当浏览器关闭时，cookie就失效了
expires

必须完全采用GMT时区的格式，可以使用data.toUTCString来获取

例如：expires = Tue, 19 Jan 2038 03:14:07 GMT

max-age

过期时间距离当前时间的秒数

例如：max-age=60

cookie的作用域

domain和path标识定义了cookie的作用域，即cookie应该发送给哪些URL

domain

标识指定了哪些主机可以接受cookie
如果不指定，默认为当前文档的主机（不包含子域名）；如果指定了domain，则一般包含子域名
例如：如果设置domain=520it.com,则cookie也包含在子域名中（如bbs.520it.com）

path

标识制定了主机下的哪些路径可以接受cookie，子路径也会被匹配
例如：设置path=/docs，则以下地址都会匹配

√ /docs

√ /docs/one/

√ /docs/one/img

服务器设置cookie

cookie通常是由web服务器使用响应头Set-cookie设置的
关于max-age

在Javascript中：如果设置为0或者负数，会立即删除cookie

在Java中：如果设置为0，时立即删除cookie；如果设置为负数，按默认情况处理。

getSession内部原理

检查客户端是否有发送一个叫JSESSIONID的cookie

如果没有

创建一个新的Session对象，并且这个Session对象会有一个id
这个Session对象会保留在服务器的内存中
在响应的时候，会添加一个cookie（JSESSIONID=Session对象的id）给客户端

如果有

返回id为JSESSIONID的Session对象

JSESSIONID

默认情况下，当用户关闭浏览器时，cookie中存储的JSESSIonID 就会被销毁
可以通过以下代码延长JSESSIonID 在客户端的寿命

Session的有限期

Session的有效期默认是30分钟
可以在web.xml中配置失效时间（单位是分钟）

总结

数据存储在浏览器客户端
数据有大小和数量限制
适合存储一些小型、不敏感的数据
默认情况下，关闭浏览器后就会销毁

Session

数据存储在服务器端
数据没有大小和数量的限制
可以存储大型、敏感的数据（比如用户信息）
默认情况下，未使用30分钟后就会销毁

状态码（Status Code）

在规范中定义

状态码指示HTTP请求是否已成功完成

状态码可以分为5类

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

常见的状态码

（每个状态码都有一个英文描述）

100 Continue

        请求的初始部分已经被服务器收到，并且没有被服务器拒绝。客户端应该继续发送剩余的请求，如果请求已经完成，就忽略这个响应
        允许客户端发送带请求体的请求前，判断服务器是否愿意接收请求（服务器通过请求头判断）
        在某些情况下，如果服务器在不看请求体就拒绝请求时，客户端就发送请求体是不恰当的或低效的

200 OK：请求成功
302 Found：请求的资源被暂时的移动到了由Location头部指定的URL上
304 Not Modified：说明无需再次传输请求的内容，也就是说可以使用缓存的内容（第一次访问，如果是成功的话，肯定是返回200，，如果是像图片，CSS，JS这种静态资源，一般都会缓存到客户端，如果进行刷新，那肯定要重新发一次请求给服务器，服务器发现这次请求的内容，上一次已经给过了，在服务器这边就没有动（修改）过，就直接使用那个缓存就可以了，这个时候，服务器就返回给一个响应，返回一个304）
400 Bad Request：由于语法无效，服务器无法理解该请求（也可能是缺少什么参数），这个码是由开发人员决定的
401 Unauthorized：由于缺乏目标资源要求的身份验证凭证
403 Forbidden：服务器端有能力处理该请求，但是拒绝授权访问
404 Not Found：服务器端无法找到所请求的资源
405 Method Not Allowed：服务器禁止了使用当前HTTP方法的请求（有能力处理，但是就不给你处理，比如：添加商品，服务器要求必须用POST方法，如果不用POST，那就发回一个405）
406 Not Acceptable：服务器端无法提供与Accept-Charset以及Accept-Language指定的值相匹配的响应
408 Request Timeout：服务器想要将没有在使用的连接关闭
一些服务器会在空闲连接上发送此信息，即便是在客户端没有发送任何请求的情况下
500 Internal Server Error：所请求的服务器遇到意外的情况并阻止其执行请求
501 Not Implemented：请求的方法不被服务器支持，因此无法被处理
服务器必须支持的方法（即不会返回这个状态码的方法）只有 GET 和 HEAD
502 Bad Gateway：作为网关或代理角色的服务器，从上游服务器（如tomcat）中接收到的响应是无效的
503 Service Unavailable：服务器尚未处于可以接受请求的状态
通常造成这种情况的原因是由于服务器停机维护或者已超载