IT数码 购物 网址 头条 软件 日历 阅读 图书馆
TxT小说阅读器
↓语音阅读,小说下载,古典文学↓
图片批量下载器
↓批量下载图片,美女图库↓
图片自动播放器
↓图片自动播放器↓
一键清除垃圾
↓轻轻一点,清除系统垃圾↓
开发: 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可靠传输

  • 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流量控制

  • 接收方根据自己的接收能力让发送方控制一下发送熟虑
  • 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-报文结构

  • HTTP请求报文,HTTP响应报文
  • 请求报文和响应报文都是由开始行,首部行,实体主体构成
  • 开始就是get post put之类的
  • 首部行可以有很多行,也可以不用,首部行格式为 字段名:字段值
  • CRLF是回车换行

在这里插入图片描述
具体例子
在这里插入图片描述

第六章总结

在这里插入图片描述

  网络协议 最新文章
软件评测师——安全性基础知识
从R星《GTA 6》数据泄露事件浅谈核心数据安
计算机网络传输层补充总结
安全算法介绍
Java网络编程/TCP编程
TCP与UDP的区别
第三章 广域网技术
知识梳理(五)
动态路由协议
TCP安全可靠!!!!!!!
上一篇文章      下一篇文章      查看所有文章
加:2022-06-29 19:26:03  更:2022-06-29 19:26:55 
 
开发: C++知识库 Java知识库 JavaScript Python PHP知识库 人工智能 区块链 大数据 移动开发 嵌入式 开发工具 数据结构与算法 开发测试 游戏开发 网络协议 系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑 笔记本 显卡 显示器 固态硬盘 硬盘 耳机 手机 iphone vivo oppo 小米 华为 单反 装机 图拉丁
360图书馆 购物 三丰科技 阅读网 日历 万年历 2022年10日历 -2022/10/6 16:31:37-
图片自动播放器
↓图片自动播放器↓
TxT小说阅读器
↓语音阅读,小说下载,古典文学↓
一键清除垃圾
↓轻轻一点,清除系统垃圾↓
图片批量下载器
↓批量下载图片,美女图库↓
  网站联系: qq:121756557 email:121756557@qq.com  IT数码