文章目录
- 1 DNS
1 DNS
- 全称Domain Name System， 域名系统。
- 传输层使用UDP协议，端口为53
1.1 域名
- 域名由 “标号.标号.标号”组成
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Rk1b92vm-1613753140851)(en-resource://database/2048:1)] - 标号由字母和“-”组成。
- 标号不超过63个字符
- 总域名（标号之和）不能超过255
- 分为根、顶级、二级、三级
- 顶级域名分类：
- 国家顶级域名nTLD: 例如cn\us
- 通用顶级域名gTLD:例如com\net\gov
- 基础建设顶级域（arpa）
4.测试顶级域
- 域名和ip可以是多对多的关系， 即1个域名可以对应多个ip（分布式多活）， 1个ip也可以被绑定成不同的域名。
1.2 域名服务器
- 每个域名和ip的对应关系都会存在域名服务器中。
- DNS采用分区的方式，解决域名服务器过多的问题，每个域名服务器管理一个区。
- 分布式部署，C/S模式
1.3 域名查找机制
1.3.1 迭代查找（最常用）
- 查找域名时，会先根据缓存，再根据本机host文件
- 当本地都没有，就会启动dns域名查找机制。
- 迭代查找记住就是会以本地DNS服务器为关键节点， 先去根域名寻求顶级域名服务器的ip
- 再去顶级域名却寻二级域的位置， 最后再去权威DNS服务器查找最终位置。
- 注意像根域名服务器的位置一般也会做缓存，所以1、2、3这几步一般也是不用重复去做的，很可能查询一个陌生的域名时，直接在本地DNS那边定位到了4那一步。
1.3.2 递归查找（很少）
递归其实就是从根域名如果找不到， 则让根域名发起请求向顶级域名查询。
即发起请求的对象变了，这种显然会占用根域名服务器的客户端资源，明显不好。
2 FTP文件传送协议
基于TCP传输，可靠性高。
2.1 文件上传过程
客户端发送PASV命令
可以看到FTP服务器会给每个连接建立相应独立的控制进程和数据进程。
2.2 文件下载过程
其实就是发送了PORT命令：
PORT h1,h2,h3,h4,p1,p2 (h1-h4是IP地址，p1-p2是端口号)
可以看到下载过程是FTP服务器向对方发起连接
- 注意上面发起会话时，会有身份认证的过程，同时也可以配置用户权限。
- FTP不适合在2个计算机直接进行共享读写文件（因为会进行资源占用）， 只适合单次的上传和下载。
3 TFTP 简单文件传送协议
- 使用UDP传输
- 支持文件传输但是无交互命令
- 应用层报文按序编号
- 熟知端口为69
- 代码轻量，程序占用小
- 传输过程类似于停止-等待协议:
单帧滑动-停止等待协议
- 一次只发一帧，1次只收一帧，并确认占有信道后才继续
- 发送端：收到ack确认后，才会发下一个，每个都有个定时器
- 接收端：序号不匹配递增的话都会丢弃。
4 P2P文件传输
FTP和TFTP，都可能是有人把文件存在一个集中的服务器上，大家去下载上传。
而P2P则是建立了主机和主机间的直接通信， 不需要依赖中间服务器
- 类似于别人直接从你电脑的目录上下载文件而不是从百度网盘里下载
4 SMTP电子邮件协议
4.1 组件构成
4.1.1 用户代理UA（user agent)
其实就是邮件客户端，类似于foxmail、outlook、qq邮箱等exe程序，
4.1.2 邮件服务器
- 功能： 发送和接收邮件，报告邮件的传送情况
- 具备C/S工作模式： 发送邮件时是一个客户端，接收邮件时是一个服务端
- 不同邮件提供商有自己的服务器，但是他们之间可以互相通信。
4.1.3 协议
使用SMTP接收协议和POP读取服务完成整套邮件系统协议。
4.2 通信步骤
4.2.1 连接建立
- 用户使用UA发送邮件到自己UA所属的邮件服务器
- 服务器定期扫描，发现有新的未发送邮件
- 向目的端服务器试图建立连接
4.2.2 邮件传送
- 发送端发送MAIL命令
- 接收端回答“250 OK”，即准备好接收
- 发送端发送多个"RCPT+ 收件人"的命令， 以向对方确认是否可以接收
- 接收端逐一应答“250 ok”或者“550 no such user”
- 获得ok应答后，使用DATA命令发送邮件内容
- 接收端回复 354 xxx end xxx., 告知邮件接收结束
4.2.3 连接释放
发送端发送QUIT命令
接收端返回221同意释放连接
4.2.4 POP推送给客户端UA
注意前面3步只是完成了从发送者到 接收者所属邮件服务器的步骤，还没有到接收者本地的邮箱应用。
接收者客户端会通过POP协议定期去拉取邮件。
5 HTTP协议
这个最好看图解HTTP笔记里的内容。
5.1.1 Http为什么是无连接 和无状态的？
- 一.无连接：每一个访问都是无连接，服务器挨个处理访问队列里的访问，处理完一个就关闭连接，这事儿就完了，然后处理下一个新的无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接
- 二.无状态：
- 协议对于事务处理没有记忆能力
- 对同一个url请求没有上下文关系
- 每次的请求都是独立的，它的执行情况和结果与前面的请求和之后的请求是无直接关系的，它不会受前面的请求应答情况直接影响，也不会直接影响后面的请求应答情况
- 服务器中没有保存客户端的状态，客户端必须每次带上自己的状态去请求服务器
5.1.2 那么HTTP的持久连接又是怎么回事？
在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。
Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。
实现长连接需要客户端和服务端都支持长连接。
HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。
TCP短连接长连接都由客户端发起，而TCP长连接的保活功能主要为服务器应用提供。
如果客户端已经消失而连接未断开，则会使得服务器上保留一个半开放的连接，而服务器又在等待来自客户端的数据，此时服务器将永远等待客户端的数据。保活功能就是试图在服务端器端检测到这种半开放的连接。也因为短连接、长连接的实现在HTTP之外，与HTTP无关，从HTTP自身来看，HTTP依然是无连接的
