- 学习过程对书本的内容的摘要以及总结,逐步完善,带有个人理解成分。
Web 及网络基础
使用 HTTP 协议访问 Web
- 客户端:通过获取请求获取服务资源的 Web 浏览器等
- HTTP 全称:HtyperText Transfer Protocol
- WWW 全称:Wrold Wide Web
- SGML 标准通用标记语言 全称:Standard Generalized Markup Language
网络基础 TCP/IP
- TCP/IP 协议族,或指TCP、IP
- 协议族常见协议:TCP、UDP、IP、PPPoE、DNS、SNMP、ICMP 等
TCP/IP 的分层管理
分为四层:应用层、传输层、网络层、数据链路层
应用层
- 决定了向用户提供应用服务时通信的活动
- 预存了各类通用的应用服务。如:DNS、FTP
- HTTP 协议也在该层
传输层
- 对上层应用层,提供处于网络连接中的两台计算机之间的数据传输协议
- TCP、UDP在其中
网络层(网络互连层)
- 处理网络上的流动数据包。
- 数据包:网络传输的最小单位。
- 规定了通过了怎样的传输路径(传输路线)到达对方的计算机,并把数据包给对方。
链路层(数据链路层、网络接口层)
- 处理连接网络的硬件部分。
- 例如:控制操作系统、硬件的设备驱动、光纤等,硬件范围。
TCP/IP 通信传输流
- 发送端:应用层往下走。接受端相反
- 发送端:层与层之间传输数据的时候会把对应的首部信息打上。反之消去首部。
- 把数据包装起来的做法叫封装。
与 HTTP 密切相关的协议:IP、TCP 和 DNS
负责传输的 IP 协议
- IP:Internet Protocol 位于网络层的网际协议。
- 把各自数据包传送给对方。
- 要保证确实传输到对方那里,需要满足各类条件。其中两个重要的是:IP 地址和 MAC 地址(Media Access Control Address)。IP 地址指明了节点被分配的地址,MAC 地址是指网卡所属的固定地址。
- IP 地址可和 MAC 地址相互匹配,IP 地址可变换, MAC 地址基本上不会更改。
使用ARP协议(Address Resolution Protrocol)协议
- 是一种用以解析地址的协议。
- 根据通信方的IP地址就可以反查出对应的 MAC 地址。
确保可靠性的 TCP 协议
-
位于传输层,提供可靠的字节流服务。
-
字节流服务:为方便传输,将大块的数据分割成报文段(segment)为单位的数据包进行管理。(为了传输大数据才将数据进行分割)
-
可靠的服务:把数据准确的传输给对方。
-
确保能到达目标。
-
- 采用三次握手策略(three-way handshaking)策略。
- 使用了 TCP 标志:(flag)—SYN(synchronize) 和 ACK(ackonwledgement)
负责域名解析的 DNS 服务
- DNS(Domain Name System)是位于应用层的协议。同 HTTP 一样。
- 提供域名到 IP 地址之间的解析服务。可逆向查询。
- 计算机可被赋予 IP 地址,也可被赋予 主机名和域名。通常用主机名或域名,因为符合人类记忆习惯。
各种服务与 HTTP 协议的关系
- 想想想想
URI 和 URL
- URI:Uniform Resource Identifier 统一资源标识符。
-
- Uniform 规定统一的格式,方便处理多种不同类型的资源。
- Resource 资源的定义是“可标识的任何东西”。除文档文件、图形或服务等能够区别与其他的,全部可做资源。资源不仅可单一,也可以是多数的集合体。
- Identifier 表示可标识的对象。也称标识符。
- 就是由某个协议方案表示的资源定位符。协议方案是指访问资源时使用的协议的类型名称。例如:采用 HTTP 协议的时候,协议方案就是 http。除此之外,还有ftp、file等30多种。
URI 用字符串标识着某一互联网资源,URL 表示资源的地点。
可见,URL 是 URI 的子集。
- URL:Uniform Resource Locator 统一资源定位符。
URI 格式
- 表示指定的 URL ,要使用涵盖全部必要信息的 绝对 URL 、绝对 URL 以及相对 URL 以及相对 URL 。相对 URL ,是指从浏览器中基本 URL 处指定的 URL,形如 /image/logo.gif
绝对 URL 的格式:
http:// user:pass @ www. exanple.jp: 80 / dir/index.htm ? uid=1 # ch1
- http:// 协议方案名。不区分大小写。
- user:pass 登录信息(认证)。可选信息。
- www. exanple.jp: 服务器地址。
-
- 使用绝对的URL必须指定待访问的服务器地址。
- 地址可以是类似 hackr.jp 这种DNS 可解析的名称,也可以是 192.168.1.1 这种类似 IPv4 地址名,还可以是 [0:0:0:0:0:0:0:1]这种方括号括起来的 IPv6 地址名。
- 80 服务器端口号。可选项。省略则使用默认的端口号。
- dir/index.htm 带层次的文件路径。与 UNIX 系统的文件目录结构类似。
- uid=1 查询字符串。针对已指定的文件路径内的资源。可选。
- ch1 片段标识符。通常可标记出已获取资源的子资源。可选。 RFC 中没有规定其使用方法。
RFC(Request for COmments)征求修正意见书
制定 HTTP 协议技术标准的文档。
简单的 HTTP 协议
HTTP 协议用于客户端和服务端之间的通信
- 必定是一端担任客户端角色,另一端担任服务器角色。
通过请求和响应的交换达成通信
- 请求必定由客户端发出,服务端回复
实例:
客户端发给某个服务器的请求报文中的内容。
GET /index.htm HTTP/1.1
Host : hacker.jp
- GET 请求访问服务器的类型,称为方法(method)。
- /index.htm 指明了访问的资源对象。称为 请求URI(request-URI)。
- HTTP/1.1 是 HTTP 的版本号。
意思是:请求访问某台 HTTP 服务器上的 /index/htm 页面资源
// 服务器
HTTP/1.1 200 OK
Date: Tue, 1 Jan 2020 08:00:01 GMT
Content-Length: 362
Content-Type: text/html
请求报文是由请求方法、请求URL、协议版本、可选的请求首部字段和内容实体构成。
- HTTP/1.1 表示服务对应的 HTTP 版本。
- 200 OK 表示请求的处理结果的状态码(status code)和原因短语(reason-phrase)。
- 下一行显示响应的时间,是首部字段(header field)内的一个属性。
- 接下来,空一行 分隔,之后的内容称为资源实体的主体(enntity field)
- GMT 是响应首部字段。
HTTP 是不保存状态的协议
- 无状态协议(stateless)
- HTTP 这个级别,协议对于发送请求或响应都不做持久化处理。
- 每当有新的请求,即产生新的响应,不保存之前的响应报文信息。
- 为了保持状态,引入 Cookie 技术。
请求 URL 定位资源
- 类型很多种。。。
如果不是访问特定的资源,而是对服务器本身发起请求,可以用一个 * 来代替请求URI。例如:
OPTIONS * HTTP/1.1
告知服务器意图的 HTTP 方法
GET :获取资源
- GET 方法用来请求访问已被 URI 识别的资源。
- 指定的资源经服务端解析后返回响应内容。如果请求资源是文本,那就保持原样返回;如果是像 CGI(Common Gateway Interface) 通用网关接口那样的程序,则返回经过执行后的输出结果。
例子:
请求 | Get /index.html http/1.1 |
---|---|
响应 | 返回 index.html 的页面资源 |
请求 | Get /index.html http/1.1 Host: www.hackr. jp if-modified-since: thu, 1 jan 2020 08:20:01 gmt |
---|---|
响应 | 仅返回2020年1月1日8点20分以后更新过的index页面资源。 |
POST:传输实体主体
- 用来传输实体的主体。
例子:
请求 | post /submit.cgi http/1.1 Host: www.hackr. jp content-length:1560(1560字节的数据) |
---|---|
响应 | 返回 submit.cgi 接收数据的处理结果 |
PUT:传输文件
- 传输文件,像 FTP 一样。
- 要求在请求报文主体中包含文件内容,然后保存到请求 URI 制定的位置。
- HTTP/1.1 自身不带验证机制。存在安全问题,一般不用。
- 若配合 Web 应用程序的验证机制,或采用 REST(REpresentational State Transfer,表征状态转移) 标准的同类 Web 网站,可能会使用。
例子:
请求 | put /example.html http/1.1 host: www.hackr .jp content-type: text/html content-length: 1560 (1560字节的数据) |
---|---|
响应 | 响应返回状态码 204 Not Content (比如:该 html 已存在于服务器上) |
HEAD:获得报文首部
- HEAD 方法和 GET 方法一样,不返回报文主体部分。
- 用于确认 URL 的有效性及资源更新的日期时间等。
例子:
请求 | head /index.html http/1.1 host: www.hackr .jsp |
---|---|
响应 | 返回 index.html有关的响应首部 |
DELETE:删除文件
- 用来删除文件,是与 PUT 相反的方法。
- 但是和 HTTP/1.1 一样,不带验证机制,所以一般的 Web 网站也不使用 DELETE 方法。
- 当配合 Web 应用程序的验证机制,或遵循 REST 标准时还是有可能会开放使用。
例子:
请求 | DELETE /example.html HTTP/1.1 |
---|---|
响应 | 响应返回状态码 204 No Content (比如:该 html 已从该服务器上删除) |
OPTIONS:询问支持的方法
例子:
请求 | OPTIONS * HTTP/1.1 Host:www.hackr .jp |
---|---|
响应 | HTTP/1.1 200 OK Allow: GET, POST, HEAD, OPTIONS(返回服务器支持的方法) |
TRACE:追踪路径
- 让 Web 服务器端将之前的请求通过通信回环给客户端的方法。
- 在 Max-Forwards 首部字段中填入数值,每经过一个服务器就将该数字减1,当数字减到 0 时,就返回状态码 200 OK 的响应。
- 客户端通过 TRACE 方法查询发送出去的请求是怎样被加工修改/篡改的。因为请求连接到源目标服务器可能会通过代理中转,TRACE 方法就是用来确认连接过程中发生的一系列操作。
- 不常用。易引发 XST(Cross-Site Tracing,跨站追踪)攻击。
例子:
请求 | TRACE / HTTP/1.1 Host: hackr.jp Max-Forwards:2 |
---|---|
响应 | HTTP/1.1 200 OK Content-Type: message/http TRACE / HTTP/1.1 Host: hackr.jp Max-Forwards:2 (返回响应包含的请求内容) |
CONNECT:要求要用隧道协议连接代理
- 要求在与代理服务器通信时建立隧道,实现用隧道协议进行 TCP 通信。
- 主要使用 SSL (Secure Sockets Layer,安全套接层) 和 TLS(Transport Layer Security,传输层安全)协议把通信内容加密后经网络隧道传输。
- 语法格式:CONNECT 代理服务名:端口号 HTTP版本
例子:
请求 | CONNECT proxy.hackr.jp:8080 HTTP/1.1 Host: proxy.hackr.jp |
---|---|
响应 | HTTP/1.1 200 OK(之后进入网络隧道) |
使用方法下达命令
- 向请求 URI 制定的资源发送请求报文时,采用成为方法的命令。
- 方法的作用在于,可以指定请求的资源按期望产生某种行为。方法中有 GET、POST 和 HEAD 等。
支持的方法
方法 | 说明 | 支持的 HTTP 协议版本 |
---|---|---|
GET | 获取资源 | 1.0、1.1 |
POST | 传输实体主体 | 1.0、1.1 |
PUT | 传输文件 | 1.0、1.1 |
HEAD | 获取报文首部 | 1.0、1.1 |
DELETE | 删除文件 | 1.0、1.1 |
OPTIONS | 询问支持的方法 | 1.1 |
TRACE | 追踪路径 | 1.1 |
CONNECT | 要求用隧道协议连接代理 | 1.1 |
LINK | 建立和资源之间的联系 | 1.0 |
UNLINE | 断开连接关系 | 1.0 |
持久连接节省通信量
- 之前的情况:每进行一次 HTTP 通信就要断开一次 TCP 连接。
持久连接
- 持久连接(HTTP Persistent Connections),也称为 HTTP keep-alive 或 HTTP connection reuse。
- 特点:只要任意一端没有明确提出断开连接,则保持 TCP 连接状态。
- 在 HTTP/1.1 中所有的连接默认都是持久连接。
管线化
- 使用管线化技术,不用等待响应即可直接发送下一个请求
使用 Cookie 的状态管理
- HTTP 协议,无协议也有好处,简单才会被更多的应用。
Cookie 技术:通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。
Cookie 会根据从服务器端发送的响应报文内的一个叫 Set-Cookie 的首部字段信息,通知客户端保存 Cookie。
下次再客户端再往该服务器发送请求时,客户端会自动再请求报文中加入 Cookie 值后发送出去。
- HTTP 请求报文和响应报文内容如下:
1.请求报文(没有 Cookie 信息的状态)
GET /reader/ HTTP/1.1
Host: hackr.jp
- 首部字段内没有 Cookie 的相关信息
2.响应报文(服务器端生成 Cookie 信息)
HTTP /1.1 200 OK
Date: Tue, 1 Jan 2020 08:10:01 GMT
Sever: Apache
<Set-Cookie:sid=13420770140226734; pa+10-jan-11 08:10:01 GMT>
content-Type: text/plain; charaset=UTF-8
3.请求报文
GET /image/ HTTP/1.1
Host: hackr.jp
Cookie: sid=1342077140226724
来源:oschina
链接:https://my.oschina.net/u/4279029/blog/4263319