每个应用层协议是为了解决某一类问题，
大部分应用层协议采用的是客户服务器模式
DNS（Domain Name System）
域名系统，从域名解析出IP
域名结构
小数点分开，从后向前依次是顶级域名，一级域名，二级域名。。。
redarm.cn：
cn：顶级域名
redarm：二级域名
域名分类
1.国家顶级域名：
- cn：中国
- us：美国
- uk：英国
2：通用顶级域名：
- com：公司企业
- net：网络服务机构
- org：非营利性组织
- int：国际组织
- mil：美国军事部门
树形域名结构：
域名服务器
用来解析域名的服务器
树形域名服务器：
1.根域名服务器：
所有的根域名服务器都知道所有的顶级域名服务器和IP地址
操作系统中带有请求根域名服务器IP方式，自动寻找更新根域名服务器
电脑输入一个域名后，如果自己无法解析首先寻找根域名服务器查找IP
全世界有588个更多的根域名服务器
根域名服务器只有13个不同IP地址的域名：比如a.rootservers.net, b.rootservers.net.....
也就是说每个根域名有很多的服务器运行在全世界各地，构成服务器集群
2.顶级域名服务器
负责管理一个顶级域名的所有二级域名和对应的IP
3.权限域名服务器
负责一个区的域名服务器
4.本地域名服务器
主机发送DNS请求时会发送给本地域名服务器去解析
一个大学就可以建立一个本地域名服务器
DNS缓存顺序
1.浏览器缓存
2.本地内存中缓存
3.本地操作系统中缓存：HOSTS文件中
Windows：C:\Windows\System32\drivers\etc
Mac：/etc/hosts
4.路由器
5.ISP的DNS服务器
6.根服务器
域名解析方式
1.递归查询：去本地服务器中查询，如果没有本地服务器会自己去根域名服务器中查找，而且这个过程不会让主机知道，本地服务器会返回给主机两个结果，找到或者报错
2.迭代查询：根域名服务器收到要查询的域名后，如果有就直接返回，如果没有就告诉本地服务器这个域名中顶级域名服务器的地址，让本地服务器自己去顶级域名服务器中找。
FTP（File Transfer Protocol）
文件传输协议，交互式访问，允许客户指明文件类型和格式，允许文件存储权限
一共两大类文件传输方式
- 基于TCP或者UDP的TFTP：复制整个文件，如果要传送一个文件，需要首先在本地创建一个文件的副本
- FTP：联机访问，允许多个程序同时对一个文件进行存取，操作系统对远地的文件进行访问就像是访问本地一样
FTP使用客户服务端模式，服务端有一个主进程负责处理新的请求，有多个从进程，负责单个请求。
远程终端协议TELNET
通过TCP连接远程连接到远端的主机上，实时传输键盘的击键，所以又称作仿终端协议
中断进程 control + c
万维网 WWW （word wide web）
大规模，联机式的信息存储所，简称Web
使用连接的方法，从一个站点连接到另一个站点，查看站点的文档
超文本：指向其他文档连接的文本
万维网采用客户端服务端的方式，客户端向服务端发送请求，服务端向客户端发送所要的万维网
客户端窗口显示的万维网文档又叫做 page（页面）
URL（统一资源定位符）：为了标志在整个互联网中的唯一一个文档
HTTP（超文本传输协议）：万维网的客户端和服务端要遵守HTTP协议
HTML（超文本标记语言）：统一万维网文档格式
URL
互联网上的每一个资源都有一个唯一的URL
URL格式：
- 协议：使用什么协议获取万维网的文档，最常用的就是http，其次是ftp
- 主机：文档在哪一个主机上，可以是IP，也可以是域名
- 端口和路径：有时可以省略
使用HTTP的URL：
格式：
HTTP默认端口80，通常可以省略
如果路径也省略了，那个默认找到的是主页（home page）
比如：访问我的博客 redarm.cn ，这个域名是在DNS服务器上解析的对应的IP地址为 x.x.x.x ，如果你在浏览器中输入redarm.cn，那么就会去DNS服务器上查找到IP，并且因为HTTP默认的是80端口，所以其实访问的是 x.x.x.x:80， 但我的博客的服务部署的进程端口 是 8090端口，所以我需要在这之间部署一层Nginx反向代理，Nginx监听80端口，如果在80端口访问的服务并且域名为redarm.cn，那么就重定向的访问本机的8090端口的进程，所以比如我的另一个服务 假如是 x.redarm.cn ，如果访问这个域名，这个域名解析的也是我的服务器的IP地址，所以如果使用http协议访问这个域名也是去我的服务器访问80端口，只不过在Nginx中重定向到了服务器的的另一个端口的服务进程。
URL中字母不区分大小写
HTTP
HTTP协议定义了浏览器怎样向万维网服务器请求万维网文档，以及服务器怎样传给浏览器
HTTP是基于事务的，可以传输图像，文本，音频，视频等
服务器的进程持续监听80端口，如果有浏览器向80端口建立的TCP连接，浏览器发送某个页面的请求，服务器返回这个页面
浏览器和服务器之间的请求和响应格式需要遵守协议，这个协议就是HTTP协议
HTTP使用了面向连接的TCP协议，保证了数据传输的可靠性
HTTP协议本身是不需要连接的，只是他基于的TCP是需要连接的
HTTP是无状态的，服务器不会记录哪个浏览器发送了什么请求
请求过程：
浏览器输入一个URL后：首先需要与服务器建立TCP连接，三次握手的前两次握手成功后，在第三次的握手中加入HTPP报文，然后服务器就会处理这个报文，返回响应报文给客户端
所以处理一个HTTP请求需要接受请求报文的时间加上两个RTT（往返时延）
HTTP/1.0的主要缺点就是每次请求一个文档都需要两倍RTT时延
HTTP/1.1 使用了持续连接解决了这个问题，也就是服务器返回一个响应之后不会立即关闭连接，而是等待一段时间，可以继续处理HTTP请求
HTTP请求和响应报文格式：
请求报文格式：
响应报文格式：
HTTP协议是面向文本的，报文中的字段都是ASC码
请求报文和响应报文的不同之处只在于请求开始行
首部行：可以后很多的字段名和他的值
请求报文的第一行只有三个内容，方法，URL，HTTP版本
方法：
方法和URL和HTTP版本之间都是有一个空格的
比如： get redarm.cn HTTP/1.1
例子：
响应体的第一行叫状态行，包括三个内容：HTTP版本，响应码，解释响应码
响应码以及解释：
Cookie（在服务器上存储用户信息）
为了解决HTTP的无状态，想要在服务器上记录区分用户万维网规定可以使用Cookie来追踪用户
Cookie工作流程：
用户访问服务器，服务器会为用户产生一个Cookie的标识码存储在服务器的数据库上，并在响应报文中体现Cookie
响应报文的首部中使用Set-cookie字段表示标识码
比如：
浏览器收到这个响应后就会取出其中的Cookie值，并且把服务器的主机名和Cookie值加到浏览器的Cookie文件中，之后每次发送请求就会在请求报文首部加上Cookie，比如：
所以服务器就可以知道哪些请求是同一个用户发出的，而且不知道这个用户的姓名等信息
Cookie只是一个小小的文本文件，不是可以执行的程序，不会带来病毒，不会泄露用户信息