计算机网络——哈工大

HTTP协议

HTTP1.1 是一种 不保存状态，即无状态协议。对于发送的请求和响应都不做持久化处理。

这主要是为了 更快的处理大量的事务，确保协议的可伸缩性。

但是很多情况下，需要保存之前的状态，比如登录状态、购物网站的购物车等等。因此引入了Cookie 会话技术，用于管理状态。、

使用URI定位互联网上的资源。

HTTP中使用的方法;

​ GET方法 ： 获取资源

​ 用来请求访问已经被URI识别的资源。

​ POST： 传输实体主体

​ POST方法用来传输实体的主体（主要目的不是获取响应的主体内容）

​ PUT：传输文件

​ 但是由于HTTP1.1的PUT方法自身不带验证机制，所以存在安全性问题。

​ 往往需要配合Web应用程序的验证机制或架构采用REST标准同类的Web网站，即可

​ HEAD: 获得报文首部

​ 用于确认URI的有效性及资源更新的日期时间等。

​ DELETE: 删除文件

​ 与PUT方法相反，其是按请求URI删除指定的资源。注意： 同样不带验证机制。

​ OPTIONS: 询问支持的方法

​ 用来查询针对请求URI指定的资源支持的方法。

​ TRACE： 追踪路径

​ 让Web服务器端将之前的请求通信环回给客户端的方法。注意：容易引发XST攻击，一般就不会用到它。

​ CONNECT: 要求用隧道协议连接代理

​ 与代理服务器通信时建立隧道，实现用隧道协议进行TCP通信。使用SSL（安全套接层）和TLS（传输层安全）协议把通信内容加密后经网络隧道传输。

持久连接

在初始HTTP初始版本中，每进行一次HTTP通信就断开一次TCP连接

这会增加通信量的开销。

因此HTTP1.1 和部分的HTTP1.0 想出了持久连接的方法。

特点是 只要任意一端没有明确提出断开连接，则保持TCP连接状态。

减轻服务器端的负载，提高Web页面的显示速度。

管线化

持久化连接使得管线化方式发送成为可能。

以前，发送请求，等待收到响应后，才可以发送下一个请求。

现在，有了管线化技术，就不用等待响应也可以直接发送。

于是便可以同时并行发送多个请求。

Cookie 状态管理

为什么要引入Cookie技术呢？

​ Http是一种无状态协议，也就是说它不会对之前发生过的请求和响应的状态进行管理，使得无法根据之前状态进行新的请求处理。但是正因为Http协议为无状态协议，所以可以极大的减少服务器的CPU和内存的消耗。

​ 基于这样的矛盾，就诞生了Cookie技术。

​ 它通过在请求和响应报文中写入Cookie信息来控制客户端的状态。

服务器端给客户端发送的响应报文中有一个叫做 Set-Cookie 的首部字段信息，Cookie技术会通知客户端保存Cookie。

于是，当下一次客户端向服务器端发送请求报文时，客户端会在请求报文中加入Cookie的值。

然后，服务端就会根据这个Cookie的值检查是哪一个客户端发来的请求，然后根据服务器上的记录得到之前的状态信息。

Http报文

Http报文：用于HTTP协议交互的信息，分为请求报文和响应报文，是HTTP通信中的基本单位，由8位组字节流组成。

​ 分为报文首部和报文主体两大块。

请求报文格式：

​ [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YHcu29Mz-1641780660108)(C:\Users\背包十年\AppData\Roaming\Typora\typora-user-images\image-20220109165207627.png)]

响应报文格式：

​ [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Gxa9B07o-1641780660111)(C:\Users\背包十年\AppData\Roaming\Typora\typora-user-images\image-20220109165237461.png)]

请求行: 包含 用于请求的方法、请求的URI 和 HTTP版本

状态行：包含表明响应结果的状态码、原因短语和HTTP版本。

HTTP传输

HTTP在传输数据时，允许按照数据原貌传输，也可以通过在传输过程中通过编码提升传输速率，通过这种方式，能有效的处理大量的访问请求。但是编码由计算机来完成，需要消耗更多的CPU资源。

实体：

​ 作为请求和响应的有效载荷数据被传输，其内容由实体首部和实体主体组成。

HTTP报文的主体用于传输请求或响应的实体主体。

一般，报文主体等于实体主体。但是当进行编码操作时，实体主体内容会发生变化。

Email 消息格式

RFC 822 ： 文本消息格式标准

​ 头部行

​ 消息体

扩展：MIME 多媒体邮件扩展 RFC2054,2056

邮件访问协议

从服务器获取邮件

POP：Post Office Protocol

​ 认证/授权和下载

IMAP

​ 功能更多

HTTP

​ 浏览器使用

POP协议

认证过程：

​ 客户端命令

​ 服务器响应

事物阶段：

“下载并删除”模式：

​ 无法重读该邮件

“下载并保持”模式：

​ 不同客户端都可以保留消息的拷贝

POP3是无状态的

IMAP协议

消息统一保存在服务器

DNS概述

在网络应用层应用的网络核心技术

Domain Name System 域名系统

分布式架构的数据库

解决Internet上主机/路由器的识别问题

​ IP地址

​ 域名

IP地址与域名之间映射： 域名解析系统DNS

DNS服务：

​ 域名翻译成 IP 地址

​ 主机别名

​ 邮件服务器别名

​ 负载均衡：Web服务器

不用集中式的DNS

​ 单点失败、流量问题、距离问题、维护性问题

DNS根域名服务器

​ 当本地域名解析

本地域名服务器：缓存、更新IP映射

DNS协议：查询和回复

如何注册域名？

域名管理机构 注册域名

​ 提供我的权威域名解析服务器的名字和IP地址

​ 由域名管理机构向com顶级域名解析服务器插入两条记录

P2P应用

Peer to Peer

没有服务器

任意端系统之间直接通信

节点阶段性接入Internet

节点可能更换IP地址

复杂、难于管理

P2P架构 被广泛的应用于文件分发、下载，其所需要的时间非常的端，且随着用户的增多，时间趋于水平

但是C/S架构的时间确实线性的

其中文件分发采用 BitTottent 协议

BitTottent 协议 即P2P 会对带宽带来严重的挤占行为

P2P:索引技术

搜索信息

索引系统：信息到节点位置（IP地址+端口号）的映射

利用索引来查找IP

文件共享（如电驴）、即时消息（如QQ）

集中式索引：

​ [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-G1LfnNab-1641780660114)(C:\Users\背包十年\AppData\Roaming\Typora\typora-user-images\image-20211218163517489.png)]

这种方式：

​ 内容和文件传输是分布式的，但是内容定位是高度集中式的

​ 故会存在单点失效问题、性能瓶颈、版权问题

分布式索引系统：

​ 洪泛式查询

​ 导致网络拥堵

​ 层次式覆盖网络

​ 介于集中式和洪泛查询之间的方法

​ [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-C7fdaCCg-1641780660115)(C:\Users\背包十年\AppData\Roaming\Typora\typora-user-images\image-20211218164439954.png)]

P2P案例应用：

​ Skype

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qy1kqOni-1641780660116)(C:\Users\背包十年\AppData\Roaming\Typora\typora-user-images\image-20211218164653776.png)]

Socket编程-应用编程接口（API）

套接字编程 介于 应用层和传输层之间

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-HtP7dECo-1641780660117)(C:\Users\背包十年\AppData\Roaming\Typora\typora-user-images\image-20211219202245630.png)]

几种典型的应用编程接口

Socket API

网络应用程序开发的标准

应用进程间通信的抽象机制

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tyJxYEFU-1641780660118)(C:\Users\背包十年\AppData\Roaming\Typora\typora-user-images\image-20211219205420681.png)]

标识通信端点（对外）：IP地址+端口号

操作系统/进程如何管理套接字（对内）？：套接字描述符

地址结构：sockaddr_in:

​ [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VO9T4JlU-1641780660118)(C:\Users\背包十年\AppData\Roaming\Typora\typora-user-images\image-20211219210339581.png)]

socket

创建套接字

操作系统返回套接字描述符

三个参数（协议族、套接字类型、协议号）

SOCK_DGRAM 面向UDP

SOCK_STREAM 面向TCP

SOCK_RAM 直接面向网络层

TCP：给应用提供服务：

​ 可靠：不会丢失、乱序

​ 面向连接

​ 字节流传输

​ 点对点

UDP：

​ 不可靠

​ 无连接

​ 数据报传输

Closesocket 函数

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-j9QfBWEN-1641780660120)(C:\Users\背包十年\AppData\Roaming\Typora\typora-user-images\image-20211220224612544.png)]

bind函数

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BANtTkQQ-1641780660121)(C:\Users\背包十年\AppData\Roaming\Typora\typora-user-images\image-20211220224908900.png)]

listen 函数

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-k6fv6dO5-1641780660122)(C:\Users\背包十年\AppData\Roaming\Typora\typora-user-images\image-20211220225325892.png)]

connect 函数

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hYeflag9-1641780660123)(C:\Users\背包十年\AppData\Roaming\Typora\typora-user-images\image-20211220225520158.png)]

accept函数

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hA5sI2qH-1641780660124)(C:\Users\背包十年\AppData\Roaming\Typora\typora-user-images\image-20211220225836817.png)]

函数小结

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3Z6i8AyG-1641780660125)(C:\Users\背包十年\AppData\Roaming\Typora\typora-user-images\image-20211220230348972.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NKUJTrO8-1641780660126)(C:\Users\背包十年\AppData\Roaming\Typora\typora-user-images\image-20211220230411996.png)]

关于网络字节顺序

TCP/IP 定义了 网络字节顺序

某些Socket API 函数的参数需要存储为网络字节顺序

注意 本地字节顺序与网络字节顺序间的转换 转换函数如下：

​ htons 、ntohs 、 htonl 、 ntohl

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1hDuojXg-1641780660127)(C:\Users\背包十年\AppData\Roaming\Typora\typora-user-images\image-20211225163613897.png)]

​

Socket编程—客户端软件设计

解析服务器IP地址

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jLZLsJNg-1641780660127)(C:\Users\背包十年\AppData\Roaming\Typora\typora-user-images\image-20211225164607630.png)]

解析服务器端口号

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-scKmSID4-1641780660128)(C:\Users\背包十年\AppData\Roaming\Typora\typora-user-images\image-20211225164825964.png)]

解析协议号

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ELCrY4kY-1641780660128)(C:\Users\背包十年\AppData\Roaming\Typora\typora-user-images\image-20211225164926586.png)]

TCP客户端软件流程

1、确定服务器IP地址与端口号

2、创建套接字

3、分配本地端点地址（IP地址+端口号）

4、连接服务器（套接字）

5、遵循应用层协议进行通信

6、关闭/释放连接

UDP客户端软件流程

1、确定服务器IP地址与端口号

2、创建套接字

3、分配本地端点地址（IP地址+端口号）

4、指定服务器端点地址，构造UDP数据报 （以数据报为单位）

5、遵循应用层协议进行通信

6、关闭/释放套接字

客户端软件的实现-connectsock()

循环无连接服务器

============================================================

传输层

传输层服务概述：

​ 传输层协议为运行在不同端系统上的应用进程之间提供了一种**逻辑通信机制。**而网络层是提供主机之间的逻辑通信机制，位于网络层之上、依赖于网络层服务，又对网络层服务进行增强。

​ 逻辑通信机制：端到端通信机制，两个进程之间仿佛是直接连接的。不用关心物理距离、有多少个路由器、媒介等

​ 作为发送方：传输层将应用递交的消息分成一个或多个的Segment，并向下传给网络层。

​ 作为接受方：传输层将接收到的segment组装成消息，并向上交给应用层。

提供了可靠的、按序的交付服务（TCP），如拥塞控制、流量控制、连接建立

也提供了不可靠的交付服务（UDP）。

但是以上两个服务均没有提供延时方面的保障。

多路复用和多路分用

多路分用：

主机接收到IP数据报，每个数据报携带源IP地址、目的IP地址，每个数据报携带一个传输层的段，每个段携带源端口号和目的端口号。

主机收到Segment之后，传输层协议提取IP地址和端口号信息，将Segment导向相应的Socket

无连接多路分用：

​ 1、利用端口号创建Socket

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YjdSeDQZ-1641780660129)(C:\Users\背包十年\AppData\Roaming\Typora\typora-user-images\image-20220109174954862.png)]

​ 2、UDP的Socket用二元组标识 （目的IP地址，目的端口号）

​ 3、主机收到UDP段后

​ 检查段中的目的端口号

​ 将UDP段导向绑定在该端口号的Socket

​ 4、来自不同源IP地址和源端口号的IP数据包被导向同一个Socket

面向连接的多路分用：

​ 1、TCP的Socket用四元组标识（源IP地址，源端口号，目的IP地址，目的端口号 ）

可靠数据传输机制

可靠： 不出错、不丢包、不乱序

基本结构：接口！

​ rdt_send() 被上层应用所调用（单向）

​ udt_send() 与网络层之间调用 双向

​ rdt_rcv() 双向

​ deliver_data() 被rdt调用，向上层应用交付数据

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KQtpxGlN-1641780660130)(C:\Users\背包十年\AppData\Roaming\Typora\typora-user-images\image-20220109194622887.png)]

rdt 1.0基于可靠信道

rdt 2.0 不可靠信道 ：产生位错误的信道

底层信道可能翻转分组中的位

​ 利用校验和检测位错误

那么，如何从错误中恢复？

​ 确认机制（ACK）：接收方显式地告诉发送方分组已正确接收

​ NAK：接收方显式地告诉发送方分组有错误

​ 发送方收到NAK后，重传分组

​ 以上可以称之为 停 - 等 协议
​ Rdt 2.0 有什么缺陷呢？

​ 如果！ACK/NAK消息发生错误/被破坏怎么办呢？

​ [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zFUptRX1-1641780660130)(C:\Users\背包十年\AppData\Roaming\Typora\typora-user-images\image-20220109211519349.png)]

Rdt 2.1 增加了 序列号 机制

​ [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LDFfIbIE-1641780660131)(C:\Users\背包十年\AppData\Roaming\Typora\typora-user-images\image-20220109211921757.png)]

Rdt 2.2 ：无NAK消息协议

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-E4HKGFuP-1641780660132)(C:\Users\背包十年\AppData\Roaming\Typora\typora-user-images\image-20220109212150896.png)]

Rdt 3.0

Rdt 1.0 —Rdt 2.2 均是在信道不会发生丢失分组的情况下 考虑的。

Rdt 3.0 需要考虑 信道既可能发生错误，也可能丢失分组。

那么原来的 “校验和 + 序列号 + ACK + 重传 ” 的方式就不够用了。

发送方发送一个数据，接收方会等待，如果数据丢失，接收方就会一直等下去，这个传输过程就 “死掉了”。

于是我们可以让 发送方等待 “合理”的时间（加入定时器），如果长时间没有收到ACK，那么就重传。但是哦，如果发生延迟，实际并没有丢失，这就导致重传产生数据重复，于是序列化机制就能够处理了。

性能很差！ 它限制了物理资源的利用。导致性能差的原因就是 停 – 等操作

流水线机制与滑动窗口协议

如何改善上述性能很差的原因呢？

上述 停 – 等 操作是基于平等 原理，发一个，接收一个。

那么是不是打破这种平等，就能提高性能呢？如，发送一个，在等待的同时，发送第二个，这样就提高性能了。

利用流水线机制，一次性多发一些，可以提高网络资源利用率。

流水线协议：

​ [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-K26XM56a-1641780660132)(C:\Users\背包十年\AppData\Roaming\Typora\typora-user-images\image-20220109214825777.png)]

若实现流水线机制，那么需要滑动窗口协议帮忙实现。

滑动窗口协议：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dUYBgFej-1641780660133)(C:\Users\背包十年\AppData\Roaming\Typora\typora-user-images\image-20220109215303897.png)]

GBN协议：

流量控制机制

拥塞控制机制

UDP协议：无连接传输服务

UDP协议基于Internet IP协议，增加了复用/分用功能和简单的错误校验。

因为IP协议是不可靠的、尽力而为的服务，故UDP协议也是提供了 “Best effort - 尽力而为” 的服务，因此UDP段可能存在丢失、和非按序到达的情况。

无连接，因此UDP发送方和接收方之间不需要握手，所以每个UDP段的处理独立于其他段。

那么？UDP为什么还存在？

​ 1、由于无需建立连接，所以延迟很短。如DNS用的就是UDP

​ 2、实现简单，无需维护连接状态

​ 3、头部开销少

​ 4、没有拥塞控制：应用可以更好的控制发送时间和速率。

由此常用于 流媒体应用，容忍数据丢失，且对速率敏感。

如何在UDP上实现可靠的数据传输呢？

​ 1、在应用层增加可靠性机制（但是开发难度很大）

​ 2、应用特定的错误恢复机制

简单的错误校验：

​ 报文段上的：checksum 目的就是检测UDP段在传输中是否发生错误（如位翻转等）。

校验方法：

​ [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-WMysFfeT-1641780660133)(C:\Users\背包十年\AppData\Roaming\Typora\typora-user-images\image-20220109183719324.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SGouT6qB-1641780660134)(C:\Users\背包十年\AppData\Roaming\Typora\typora-user-images\image-20220109183737022.png)]

TCP协议：面向连接的传输服务

TCP拥塞控制

议：无连接传输服务

UDP协议基于Internet IP协议，增加了复用/分用功能和简单的错误校验。

因为IP协议是不可靠的、尽力而为的服务，故UDP协议也是提供了 “Best effort - 尽力而为” 的服务，因此UDP段可能存在丢失、和非按序到达的情况。

无连接，因此UDP发送方和接收方之间不需要握手，所以每个UDP段的处理独立于其他段。

那么？UDP为什么还存在？

​ 1、由于无需建立连接，所以延迟很短。如DNS用的就是UDP

​ 2、实现简单，无需维护连接状态

​ 3、头部开销少

​ 4、没有拥塞控制：应用可以更好的控制发送时间和速率。

由此常用于 流媒体应用，容忍数据丢失，且对速率敏感。

如何在UDP上实现可靠的数据传输呢？

​ 1、在应用层增加可靠性机制（但是开发难度很大）

​ 2、应用特定的错误恢复机制

简单的错误校验：

​ 报文段上的：checksum 目的就是检测UDP段在传输中是否发生错误（如位翻转等）。

校验方法：

​ [外链图片转存中…(img-WMysFfeT-1641780660133)]

[外链图片转存中…(img-SGouT6qB-1641780660134)]

TCP协议：面向连接的传输服务

TCP拥塞控制