开发: C++知识库 Java知识库 JavaScript Python PHP知识库人工智能区块链大数据移动开发嵌入式开发工具数据结构与算法开发测试游戏开发网络协议系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑笔记本显卡显示器固态硬盘硬盘耳机手机 iphone vivo oppo 小米华为单反装机图拉丁

-> 网络协议 -> 计算机网络学习笔记（5.传输层 6.应用层） -> 正文阅读

[网络协议]计算机网络学习笔记（5.传输层 6.应用层）

第五章传输层

传输层概述

研究进程之间的逻辑通信问题在这里插入图片描述
传输层

主机才有的层次
网络层的首部校验和只能校验头部，不能校验数据部分，传输层可以实现数据的检错，这样就不需要网络层再检测数据部分了

在这里插入图片描述
传输层的两个协议

传输层的寻址与端口

这里的端口是软件端口/逻辑端口，标识主机进程，与路由器的硬件端口不同
端口号只需要在主机内有唯一性即可，不同主机之间的端口没有联系

在这里插入图片描述

UDP协议

用户数据报协议UDP概述

UDP不保证可靠交付，靠网络层实现可靠交付
UDP面向报文是指，UDP对于应用层传下的报文，既不合并也不拆分，对报文的长度不改变，保留应用报文的边界，
因此需要应用层选择合适的报文长度，否则就会导致报文传输到网络层过长，需要分片，降低传输效率；
无连接，不可靠，面向报文，适合实时，首部开销小

在这里插入图片描述
UDP首部格式

UDP的数据已经进入到主机了，因此也就不需要地址了，靠端口号来识别进程
源端口号可有可无，需要回复就给，不需要回复就不给，目的端口号必须有
16位UDP长度指整个UDP数据报长度（首部+数据），单位字节
16位UDP检验和检测整个UDP数据报是否有错，错就丢弃，分用时找不到目的端口号，也会对其报文，并发送ICMP差错报告报文

在这里插入图片描述
UDP校验

图中的UDP数据报的首部开头又多了个伪首部，这个伪首部很像IP数据报的首部
伪首部只会在计算校验和时才会出现，不向下传递也不向上提交
伪首部：
- 第三个字段固定为0，
- 第四个字段表示协议，封装这个UDP报文的IP数据报的首部协议字段是17，所以这里也是17
- 第五个字段UDP长度，是UDP首部+数据部分的长度，不包括伪首部

在这里插入图片描述
注意：接收端中的检验和是经过计算后的检验和

TCP协议特点和TCP报文段格式

TCP协议特点

1.面向连接（虚连接）：虚连接指这并不是实际的物理连接，实际的物理连接应该是层层封装解封装，TCP连接就好像是进程和进程直接连接了一样（疑问，难道TCP协议不是层层封装通信的？？）
2.只能点对点，无法广播和多播
3.可靠有序，不丢不重
4.全双工，收发都有缓存
5.面向字节流

在这里插入图片描述
TCP发送数据举例

发送方将要发送文件，会将发送的数据按照字节排好序，并进行编号
将要发送的时候，提前把发送的字节放入TCP的缓存中，
发送数据时，从缓存中按顺序取出一定的字节数，加上TCP首部，形成完整报文段发送出去

在这里插入图片描述
TCP报文段首部格式

考试重点，答题中经常考察对某些字段的理解
TCP报文段主要包含：首部，数据部分
首部包含：固定首部，选项，填充（凑4字节的整数倍，填全0）
- 源端口，目的端口，即字面意思
- 序号：将要发送的字节都有自己的编号（123456789…），序号字段填的就是当前的TCP报文中数据部分的第一个字节的编号，比如上图中的首部中序号字段填的就是1，如果发送456号数据，序号字段就是4
- 确认号：接收方收到了123号字节，并且知道下一个字节应该是编号4，所以回复的报文中，确认字段为4，表示期望收到4号字节
- 数据偏移：TCP报文段的数据起始处距离整个TCP报文段的起始处的距离，一个数代表4B，其实就是首部的长度，比如这里的数值为15，则表示首部的长度为60字节；为什么还要添加首部长度，可能还会有选项字段和填充字段，所以首部长度不确定
- 6个控制位：PSH和RST几乎不会考，了解即可
- 窗口：B给A发送数据，并且在窗口字段规定了B最大能接收的数据量，A收到报文以后，知道了下次给B发送数据不要超过B的最大接收量；比如，B给A发送的确认为701，窗口为1000，那么A下次就可以给B发送701-1700号字节
- 检验和：与UDP一样，检验首部+数据，检验时加上12字节的伪首部，伪首部的第四个字段是协议字段，UDP协议中是17，TCP协议中是6
- 紧急指针：URG=1时才有意义，表示从TCP数据部分的开头向后有多少字节是紧急的数据，其实就是标记了紧急数据在数据部分中的位置和字节数
- 选项：最开始是用于记录TCP报文字段中数据部分的最大长度，后来又加了几个字段，所以选项的长度也不确定，如果不满首部字节数为4的整数倍，还需要填充字段补充一下，了解即可

在这里插入图片描述

TCP连接管理

TCP连接三次握手，TCP断开连接四次握手

TCP连接传输三个阶段

采用客户服务器方式，不论是客户还是服务器，都可以接收数据发送数据
连接建立过程就是熟知的三次握手

在这里插入图片描述
TCP的连接建立

考试重点考察三次握手过程中报文段中重要字段的数值
A想要和B通信
- A发送请求报文：SYN=1表示这是连接请求，seq=x是首部的序号字段，因为没有数据部分，所以x是随机产生的，ack是确认号，此时无效，因为上一步没有收到报文，无需期待
- B返回确认报文：B开始分配缓存和变量；SYN=1表示这是连接响应，ack=x+1表示确认，并期待收到x+1（其实本来也没有收到数据只是延续+1而已），由于B不返回数据，也随机发了seq=y，建立连接后ACK=1一直存在
- A对B的确认进行确认：A开始分配缓存和变量，SYN=0除了连接请求和响应其他时间都是0，ACK=1，seq=x+1,ack=y+1，并且A发送的报文可以携带数据

在这里插入图片描述
SYN洪泛攻击

利用TCP协议的三次握手进行攻击
攻击者不停的发送三次握手的第一个数据包，却不再对后续的服务器确认进行确认
导致服务器TCP连接一直处于挂起状态，半连接状态，浪费服务器资源，消耗大量CPU和内存，导致服务器宕机
解决办法：设置SYN cookie

在这里插入图片描述

TCP连接释放

A主动释放连接：A不再发送数据，也不再期待B发送，因此 FIN=1（释放连接时为1），seq=u
B还可以继续说（也可以不说）：A到B这个方向处于半关闭状态，ACK=1（依然是连接的），seq=v，取决于之前B发送数据到哪个位置，期待ack=u+1；A收到到B的数据传送也不会回复，只等B的结束
B主动释放连接：FIN=1表示释放连接，ACK=1因为此时还是连着的，seq=w取决于上一次发送数据的位置，期待ack=u+1，因为这段时间A一直没有发数据，
A确认B的释放连接：回复给B， ACK=1，seq=u+1，ack=w+1，但不会立刻彻底关闭连接，还需等待2MSl，因为A发送的报文可能在中途丢失；B在等待了一定时间内还会重发释放连接的报文，A一定会在2MSl内收到，如果超过了2MSL时间A没有收到，表示B已经顺利收到A的确认
如果A立即完全释放连接，B可能收不到A的确认，就会一直发送释放连接的报文

在这里插入图片描述

TCP可靠传输

TCP和UDP都是传输层协议，TCP可以实现可靠传输，UDP不可以，如果UDP需要实现可靠传输，需要借助上层实现
什么是可靠？
TCP实现可靠传输机制：校验，序号，确认，重传
校验与UDP的校验一样，都是增加伪首部
序号，确认，重传是相互交织在一起发挥作用的

在这里插入图片描述
序号

TCP面向字节流传输，传输的每个字节有对应的序号
发送方通常把几个字节放在形成报文段发送，报文段大小也是不定的，取决于链路层MTU
TCP报文的首部有序号字段，数值就是报文数据中的第一个字节的序号
比如发送蓝色报文段，序号字段就是1，发送黄色字段，序号字段就是4
有了序号字段，保证了接收方的数据有序提交
基于序号机制，可以继续实现确认，重传

在这里插入图片描述
确认

发送方发送蓝色报文段，此时发送方缓存仍然保存蓝色报文，直到收到确认，以备报文段丢失可以重传
接收方收到蓝色报文段，放在缓存中，找合适的时机一起将缓存中的几个连续报文提交
接收方接收报文段，可以直接回复一个确认的报文段，也可以在发送数据的时候捎带这个确认信息（就是首部的确认字段），称为捎带确认
接收方返回的确认报文段，首部里的确认字段为4，因为接收完123字节，期待4号字节
接收方收到确认报文段，从缓存删除蓝色报文段，准备发送黄色报文段（因为有4号字节）
接着发送方发送了黄色绿色报文段，绿色先到，黄色还没到，接收方也一直返回蓝色的确认信息，因为此时的绿色是失序的
TCP使用累积确认，即接收方只确认连续的这几个报文段的最后一个报文段的确认
发送方仍然收到蓝色确认，超过一定时间，说明黄色没被收到，会重传黄色报文段，接收方收到黄色报文段，返回绿色的确认，即确认报文段里的确认字段为9
因此确认和重传是密切相关的

在这里插入图片描述

在这里插入图片描述
重传

发送方在规定时间内没有收到确认就要重传已发送的报文段
重传时间如何确定：
- TCP的下层是互联网环境，比较复杂，每个IP数据报选择路由也不同，取决于网络情况，不好定死重传时间
- 时间过短，导致无谓的重传；时间过长，空闲过大，传输效率过低，
- 采用自适应算法，RTTS加权平均往返时间，不断地用前面的已经传输成功的往返时间算出加权平均往返时间，作为下一个报文段的重传时间
- 公式无需记忆，知道原理即可
弊端，发送要一直等，直到超过重传时间，才重传，还是太久了

在这里插入图片描述
如何不用等到重传时间就能判断出报文段已经丢失

冗余确认
其实就是在哪个位置开始失序了，就一直返回失序之前的那个确认，即使后续的收到了，也一直返回前面那个确认
因此后几次的确认都是冗余的确认，发送方收到了多个冗余确认，判定2报文段丢失，于是重传2报文段
这种技术成为快速重传

在这里插入图片描述
补充

TCP协议中使用发送缓存，发送窗口，接收缓存，接收窗口，停等协议，GBN，SR，累计确认，这些功能与链路层的功能原理大同小异，这里不再重新强调
因此发送方可以连续发送多个报文段，而不是确认一个发送一个，
TCP不经常使用停等协议，更多使用GBN，SR，接收方使用累积确认
另外TCP中的可靠传输不是重要考点，重要考点是拥塞控制，流量控制

在这里插入图片描述

TCP流量控制

接收方根据自己的接收能力让发送方控制一下发送熟虑
TCP使用滑动窗口机制来实现
发送窗口取接收窗口和拥塞窗口的最小值
接收方可以通过确认报文段或者数据报文段中的窗口字段rwnd，告诉发送方窗口设置为多大

在这里插入图片描述
TCP流量控制举例

理解了这几个发送的过程就理解了如何实现流量控制
需要注意的地方
- 第六行的报文段，A发送了401-500，不能再发送了；因为A已经接收了窗口字段为300，此时没有收到201-300的确认，所以还在内存里占据窗口的位置，因此发完了301-400，401-500，不能再发送数据了
最后一行，A收到B的601确认，但是窗口为0，A不能再发送数据，A等待B发来窗口字段大于0的报文
如果一段时间后，B把缓存数据提交，可以继续接收报文，B发给A一个报文段窗口大于0，通知A可以发送；但B的这个报文丢了，结果B一直等待A发送数据，A还在等B的通知可以开始发送数据，就会陷入死锁
解决办法，只要A接到了窗口值为0的通知，就启动计时器，超过了时间，A会给B发送探测报文段，B收到探测报文段会返回给A现在的窗口值

在这里插入图片描述

TCP拥塞控制

拥塞控制

某条链路有一定的带宽，很多流量涌入这条链路导致带宽不够使用
拥塞控制强调全局性，有多个发送方，不一定清楚是具体哪些发送方导致的；流量控制是点对点的调节
拥塞控制处理的是网络的堵塞问题，流量控制解决的是接收方接收速度跟不上发送方发送速度

在这里插入图片描述
拥塞控制四种算法

慢开始和拥塞避免在一起使用，快重传和快恢复放在一起使用
这里假定一方发送数据，另一方只回复确认；假定接收窗口能力管够，发送窗口大小只取决于拥塞程度
可以看出，接收窗口是接收方根据自己的接收能力设定的，拥塞窗口是发送方根据网络拥堵情况设定的
考试常考拥塞控制，需要非常清楚四种算法应用过程，但是具体细节不做考察；出题难度不大，但是一定要把数值看准

在这里插入图片描述
名词解释

这里我们为了方便展示，规定cwnd的单位是一个最大报文段的长度MSS，
纵坐标表示的是当前的拥塞窗口可以发送几个最大长度的报文段
横坐标单位是传输轮次，传输轮次指一批报文段从开始发送到全部接收确认的过程，考试中指一个往返时延RTT
从曲线可以看出，每经过一个传输轮次，发送方都会调整拥塞窗口的大小；感觉网络情况好就增大拥塞窗口，反之降低

慢开始和拥塞避免

所谓慢开始，就是期初拥塞窗口大小只有一个报文段，如果网络情况好，随后成指数增长（2倍）
到达慢开始门限（初始值为16）开始转变为线性增长，每轮加1，这个阶段成为拥塞避免
当出现网络拥塞（拥塞窗口24），将拥塞窗口降为1，重新开始指数增长，新的门限值设为上一次网络拥塞时拥塞窗口值的一半（这里是12）
之后的步骤以此类推
指数增长阶段，拥塞窗口的翻倍时机为，只要收到前一个轮次的报文确认就翻倍

在这里插入图片描述
快重传和快恢复

所谓快重传，和可靠传输中的冗余确认对应的快重传
如果接收方在收到某个报文段之后，接收到了后面失序的报文段，接收方只会一直返回最近的一次连续的报文段的确认
发送方收到3个重复确认，就判断当前网络情况不佳，需要进行拥塞控制的快重传算法
起始阶段指数增长，门限值初始为16，拥塞避免阶段线性增长（+1），与慢开始和慢恢复都一样
与慢开始慢恢复不同的是，发生拥塞之后，拥塞窗口直接降到新的门限值（上一次拥塞时拥塞窗口值的一半12）
然后进入到拥塞避免阶段，继续线性增长
之后的过程重复进行
Tahoe版本废弃，不用看

在这里插入图片描述

第五章总结

在这里插入图片描述

第六章应用层

网络应用模型

下层协议最终是为了应用层服务
在这里插入图片描述
应用层概述

传输层可以为应用进程提供端到端服务，但是不同的应用还需要使用不同的通信规则，应用层是为了应用程序提供服务的
应用层协议定义了什么
应用层功能
- 虚拟终端指个人计算机使用他人计算机和大型计算机进行通信，而不必使用专门使用计算机
应用层重要协议

在这里插入图片描述
网络应用模型

客户/服务器（C/S）模型

服务器接收客户请求，返回响应数据

在这里插入图片描述
P2P模型

也叫对等模型，少了服务器，只有一些主机
每个节点都具有上传和下载功能
可扩展性好，当网络有大量主机进入，主机依然可以顺利提供请求响应服务；C/S就不行，因为服务器响应能力有限制
网络健壮，有个别主机宕机对整体影响不大；C/S如果服务器宕机，就不能实现请求响应

在这里插入图片描述

域名解析系统DNS

DNS系统

主机通过IP找到另一台主机，但是IP地址不好记忆，因此我们使用域名，通过域名找到对应的IP地址
DNS实现了域名到IP地址的映射

在这里插入图片描述
域名

由英文字母，数字，点，构成
每个点分隔开的叫做一个标号，每个标号不能超过63字符，通常不超过12个字符，不区分大小写，标号里可以有横线-，其他字符不可以
域名必须是全球唯一的
标号的级别自左向右，由低到高；从右向左，分别为，顶级域名，二级域名，三级域名，等等
其实，顶级域名右侧还有个点，代表根，平时省略了
顶级域名种类，其中反向域名是用来反向解析的，即IP地址到域名的映射
二级域名种类，其中二级域名与顶级域名有重复的，比如顶级域名使用国家cn，二级域名表示分类com
三级域名，有了二级域名，可以往下申请三级域名，四级域名

在这里插入图片描述

域名服务器

域名服务器有很多，并且按照级别划分层次
划分三层：根域名服务器，顶级域名服务器，权限域名服务器
本地域名服务器不属于层次，但有重要作用，当主机发起DNS查询请求时，查询报文首先发给本地域名服务，每个因特网服务提供者（比如大学，系）都可以有本地域名服务器，也成为默认域名服务器，离主机一般不超过几个路由器；当一个主机需要查询的另一台主机就在本地域名服务器的范围里，本地域名服务器就可以直接返回解析结果，无需询问其他服务器
如果本地域名服务器查不到，就会向根域名服务器发出查询请求
根域名服务器知道下面每个顶级域名服务器的地址，根域名服务器会根据要查询的域名找对应的顶级域名服务器，再向下查找具体的权限域名服务器；
根域名服务器向下查询有两种方法：递归，根域名服务器递归向下查询到最终的IP地址并返回给主机；根域名服务器返回给主机对应的顶级域名服务器地址，主机在找顶级域名服务器，顶级域名服务器再返回给主机对应的权限域名服务器，直到主机查到了IP地址
英特网一共有13个根域名服务器，分别为a到m，比如，a.rootservers.net；每个域名服务器都是多台主机构成的集群
北美根域名服务器数量多，每个服务器可服务更少的主机，因此查询速度更快
权限域名服务器负责一个区的域名服务器，是DNS实际管辖的范围；比如，一个公司原来对应的区是abc.com，下属x部门，现在增加了一个y部门，我们可以再增加一个区y.abc.com，他与abc.com是对等的（虽然一个两级一个三级），都是顶级域名下面的一个权限域名服务器，一个权限域名服务器只能对一个区

在这里插入图片描述
域名解析过程

两种：递归查询，迭代查询
不管哪种，多需要先通过本地域名服务器在本地范围进行递归查询，然后再决定是对根域名服务器进行递归查询还是迭代查询
本地服务器查询不到，查询根域名服务器，
递归查询：本地查不到，查根域名服务器，根域名服务器如果查不到结果，往下交给顶级域名服务器查找，顶级域名服务器查不到结果，往下交给权限域名服务器查找，知道查到结果，再逐级向上返回给根域名服务器，再返回给本地域名服务器，再返回给主机；可以看到，整个过程本地服务器没啥事，上层的域名服务器一直在忙活
迭代查询：本地查不到，查根域名服务器，根域名如果找不到结果就把对应的顶级域名服务器返回跟本地，本地服务器再用这个地址查对应的顶级域名服务器，顶级域名服务器查不到结果就把对应的权限域名服务器返回给本地，本地再查，知道本地域名服务器查到对应的结果，返回给主机；可以看出整个过程，本地域名服务器一直再自己动手各种查询

在这里插入图片描述

高速缓存

可以看出域名解析的过程查找比较频繁
本地域名服务器可以使用高速缓存，保存近期查找过的域名，以及从哪里获得的域名映射信息
主机查找域名解析时，本地服务器如果有映射则直接返回，
本地没有映射，但是有对应的顶级域名IP地址，也可以直接去查找顶级域名服务器，无需再查找根域名服务器
大大减轻域名服务器压力，减少查询请求的次数，加快DNS请求速度
高速缓存会定期更新，当然主机本身也可以添加告诉缓存，保存域名的映射结果

小结

考试重点：域名解析的过程，区分递归和迭代，清楚经历了哪些域名服务器，域名服务器的具体功能

文件传输协议（FTP）

文件传输协议

主要有文件传送协议FTP，简单文件传送协议TFTP
TFTP是一个很小而且是非常易于实践的文件传送协议，非常适用于UDP环境，代码块占内存较小，容易实现，面向小文件
FTP可以屏蔽不同操作系统之间的差异性
拷贝，对应上传与下载

在这里插入图片描述
FTP服务器和用户端

基于客户/服务器（C/S）的协议
依照FTP协议提供服务的，进行文件传送的是FTP服务器；连接FTP服务器，遵循FTP协议，进行文件传送的是FTP客户端

在这里插入图片描述
FTP工作原理

登录FTP地址，输入用户名和密码，
很多服务器提供匿名登录，减轻服务器压力
FTP使用TCP可靠传输，不容的半点疏忽
客户端可以有多个，FTP服务器也可以有多个，可以同时为多个客户端服务
服务器有一个主进程，n个从属进程；首先服务器打开熟知端口21，等待客户端进行连接，然后启动n个从属进程，每个从属进程可以服务一个客户端请求

在这里插入图片描述
FTP工作原理详解

服务器有两个从属进程，控制进程和数据传送进程（主进程没有画出来）
客户端有用户界面，控制进程，数据传送进程，
客户端和服务器的控制进程建立控制连接，数据传送进程建立数据连接
控制连接在整个传送中一直存在，客户发出的传送请求都是通过控制连接发给服务器，数据连接才是实际传送数据的连接
控制连接传请求，数据连接传文件；控制连接在整个传送会话中一直存在，数据连接在文件传送完毕后就关闭，结束运行
控制连接使用端口号21，数据连接使用端口20，因此我们说FTP的控制信息是带外传送的
数据连接端口不一定是20
- 主动：如果客户端通过控制连接请求服务器传送数据，同时提供自己的数据连接端口号，服务进程就会建立数据进程，并提供端口号20
- 被动：客户端与服务器建立控制连接，客户端请求询问服务器能提供什么数据连接端口号，服务器返回一个大于1024的端口号，等待客户端，客户端再自己出一个端口号与服务器建立数据连接
- FTP传输模式，了解即可

在这里插入图片描述

电子邮件

电子邮件概述，电子邮件的信息格式

电话实时性高，但是电子邮件可以解决有时间就查看，没有时间不查看的问题

在这里插入图片描述
电子邮件系统的组成结构

包括用户代理，邮件服务器，协议，三大部分
用户代理：
- 通常是电子邮件的客户端软件，提供窗口，用户可以写邮件，发邮件，接收邮件
- 用户代理把邮件通过TCP连接，使用SMTP协议发送到邮件服务器，邮件服务器通过TCP连接使用SMTP发送到接收方的邮件服务器，收件人的用户代理通过TCP连接使用POP3协议读取邮件
邮件服务器
- 长时间工作，有大容量信箱，可以发送和接收邮件，这里的发送和接收是邮件服务器之间的；用户代理的发送和接收是用户代理和邮件服务器之间的；邮件服务器之间采用客户服务器方式连接，既可以作为客户端，又可以作为服务器
协议
- 包括发送协议（SMTP）和接收协议（POP3，IMAP）

在这里插入图片描述

简单邮件传送协议SMTP

负责发送的是客户，负责接收的是服务器
使用TCP连接，端口号25，
SMTP具体的命令和应答信息，后面详细讲解
SMTP通信三个阶段

在这里插入图片描述
SMTP通信过程

考试不会考的这么细，重点掌握这三个阶段的逻辑顺序，具体做什么的即可；复试可能会问一些细节，这了选择性记忆
1.连接建立
- 发送方服务器定期扫描邮件缓存，发现有邮件，与接收方服务器建立连接，接收服务器返回应答信息，表示可以接收，发送服务器再发送hello命令，接收服务器若有能力接收，回答250 OK，若不能接收，回答 421 service not avaliable，如果在一定时间内都不能发送，发送服务器就会告知发送方
2.邮件发送
- A表示发送方服务器，B表示接收方服务器，具体细节看图
连接释放

在这里插入图片描述
MIME

SMTP有缺陷
使用通用因特网邮件扩充MIME，可以理解为是一个协议，也可以理解为是对SMTP的一种扩充手段
是传输内容丰富多彩，支持多种数据类型的传输
现在非常适合用在浏览器上收发邮件，服务器通过MIME标识符，告知浏览器使用何种插件读取相关文件（声音，图像，视频等）

在这里插入图片描述
邮局协议POP3

只发生在接收方用户代理从接收端邮件服务器读取邮件的过程中
使用TCP连接，C/S方式，邮件服务器就是服务器，接收方就是客户端，端口号110
工作方式：下载并保留（在服务器），下载并删除
功能比较简单

在这里插入图片描述
网际报文存取协议IMAP

比POP协议复杂，也是接收端邮件服务器和用户代理之间的协议
使用更加便利，客户端打开邮箱可以看到邮件首部
可以在不同地方不同计算机随时上网读取邮件，可以只看邮件一部分，点开邮件不会马上就下载附件，点开附件才会下载

在这里插入图片描述
基于万维网的电子邮件

普遍使用的一种方式，即使用浏览器作为用户代理，非常边
用户代理与邮件服务器之间的协议是HTTP协议，邮件服务器之间还是SMTP协议

在这里插入图片描述
脑图时刻

万维网和HTTP协议

万维网概述

是无数个网站和网页的集合
通过统一的资源定位符URL找到，唯一标识每个资源，URL不区分大小写
点击超链接获取资源，资源通过HTTP协议传送给使用者
以客户/服务器方式工作，浏览器就是客户程序，文档所在的主机就是服务器
万维网使用HTML语言，让服务器响应的文本可以在浏览器显示出来

在这里插入图片描述
超文本传输协议HTTP协议

规定用户如何上网，以及如何获取请求资源
浏览器显示的时候，可以只显示文本，而不用把界面的资源全部下载，如果用户点击了声音，再重复8个步骤下载音乐

在这里插入图片描述
HTTP协议的特点

无状态：同一个客户，第二次访问界面，服务器的响应和第一次被访问的相应是相同的，没有记忆的
- 实际中，网站都希望记住用户的访问信息，使用cookie，cookie存储在本地主机，访问网站时被服务器读取，给出个性化的响应
HTTP协议采用TCP协议作为传输层协议，但HTTP协议本身是无连接的，通信双方在交换HTTP报文之前无需建立HTTP连接
HTTP连接方式
- 非持久连接
- 持久连接：非流水线，流水线

在这里插入图片描述
HTTP协议的连接方式

非持久连接：每次请求数据时，首先通过TCP建立连接（前两次握手），然后HTTP协议请求报文（第三次握手），服务器响应报文；一共耗时2倍RTT+文档传输时间，若客户再请求报文，还要重复以上动作，比较耗时
持久连接：对非持久连接的改善，用户需要请求数据，三次握手与非持久相同，连接成功后，在一段时间内客户和服务器保持着连接，若再需要请求数据，无需建立TCP连接，直接用之前的连接，直接用HTTP协议请求服务器
- 非流水线：发一个请求，收一个响应，等收到响应之后才能再请求，等响应，比较耗时，其实就是同步请求
- 流水线：可以连续发送几个请求报文，服务器收到请求，依次响应数据，效率提高了，空闲时间减少

在这里插入图片描述
超文本传输协议HTTP-报文结构