应用层
一：域名解析协议
实现解析的方式：递归解析和迭代解析。
主机向本地域名服务器的查询一般都是采用递归查询。所谓递归查询就是：如果主机所询问的本地域名服务器不知道被查询的域名的IP地址，那么本地域名服务器就以DNS客户的身份，向其它根域名服务器继续发出查询请求报文(即替主机继续查询)，而不是让主机自己进行下一步查询。因此，递归查询返回的查询结果或者是所要查询的IP地址，或者是报错，表示无法查询到所需的IP地址。
本地域名服务器向根域名服务器的查询的迭代查询。迭代查询的特点：当根域名服务器收到本地域名服务器发出的迭代查询请求报文时，要么给出所要查询的IP地址，要么告诉本地服务器：“你下一步应当向哪一个域名服务器进行查询”。然后让本地服务器进行后续的查询。根域名服务器通常是把自己知道的顶级域名服务器的IP地址告诉本地域名服务器，让本地域名服务器再向顶级域名服务器查询。顶级域名服务器在收到本地域名服务器的查询请求后，要么给出所要查询的IP地址，要么告诉本地服务器下一步应当向哪一个权限域名服务器进行查询。最后，知道了所要解析的IP地址或报错，然后把这个结果返回给发起查询的主机。
二：超文本传送协议
1：服务端回应报文的状态码
301：永久重定向，服务端会自动连接到的新的url
303：临时重定向。若原来的是post，则重定向目标应该用get请求
401：协议格式错误
403：禁止访问，拒绝服务
500：服务器内部错误
503：服务不可用
2：请求转发和重定向的区别
1、请求次数：重定向是浏览器向服务器发送一个请求并收到响应后再次向一个新地址发出请求，转发是服务器收到请求后为了完成响应跳转到一个新的地址；重定向至少请求两次，转发请求一次；
2、地址栏不同：重定向地址栏会发生变化，转发地址栏不会发生变化；
3、是否共享数据：重定向两次请求不共享数据，转发一次请求共享数据（在request级别使用信息共享，使用重定向必然出错）；
4、跳转限制：重定向可以跳转到任意URL，转发只能跳转本站点资源；
5、发生行为不同：重定向是客户端行为，转发是服务器端行为；
3：数据报文格式
http的请求数据报文：
http的响应数据报文：
4：连接管理
1）. 短连接（左图）与长连接（中图）
当浏览器访问一个包含多张图片的 HTML 页面时，除了请求访问的 HTML 页面资源，还会请求图片资源。如果每进行一次 HTTP 通信就要新建一个 TCP 连接，那么开销会很大。
长连接只需要建立一次 TCP 连接就能进行多次 HTTP 通信。
从 HTTP/1.1 开始默认是长连接的，如果要断开连接，需要由客户端或者服务器端提出断开，使用 Connection : close；
在 HTTP/1.1之前默认是短连接的，如果需要使用长连接，则使用Connection : Keep-Alive。Keep-Alive不会永久保持连接，它有一个保持时间，默认2小时，可以在不同的服务器软件（如Apache）中设定这个时间。
2）. 流水线（右图）
默认情况下，HTTP 请求是按顺序发出的，下一个请求只有在当前请求收到响应之后才会被发出。由于受到网络延迟和带宽的限制，在下一个请求被发送到服务器之前，可能需要等待很长时间。流水线是在同一条长连接上连续发出请求，而不用等待响应返回，这样可以减少延迟。
5：http和https的区别
HTTP 的URL 以http:// 开头，而HTTPS 的URL 以https:// 开头
HTTP 是不安全的 HTTPS 是安全的。HTTP 无法加密，HTTPS 对传输的数据进行加密
HTTP 标准端口是80 ，而 HTTPS 的标准端口是443
Https的具体加密的流程：
HTTPS即加密的HTTP，HTTPS并不是一个新协议，而是HTTP+SSL（TLS）。原本HTTP和TCP直接通信，而加了SSL后，就变成HTTP先和SSL通信，再由SSL和TCP通信，相当于SSL被嵌在了HTTP和TCP之间。
https采用的是对称秘钥和非对称秘钥相结合的方式：
（1） 对称加密加密与解密使用的是同样的**，所以速度快，但由于需要将密钥在网络传输，所以安全性不高。只有拥有对称加密的秘钥才能解开加密内容。
（2） 非对称加密使用了一对**，公钥与私钥，所以安全性高，但加密与解密速度慢。公钥加密的内容只有私钥可以解开，私钥签名的内容公钥可以进行验证，从而验证公钥真伪。
（3） 解决的办法是将对称加密的**使用非对称加密的公钥进行加密，然后发送出去，接收方使用私钥进行解密得到对称加密的**，然后双方可以使用对称加密来进行沟通。
1：服务器将自己的公钥发送到第三方权威CA机构
2：该CA机构返回数字证书
3：一般CA机构都是得到认证的权威机构，这些机构的根证书都是被我们的操作系统所认可的。在客户端也是已经提前安装权威机构的根证书。
4：客户端发送http请求
5：服务端返回给客户端从CA获得的数字证书
6：客户端根据根证书验证服务器返回的数字证书的可靠性。根据根证书中的写明的签名算法，对内容做签名，然后利用根证书解密签名内容，对比两个签名内容判断证书内容是否被篡改，最后获取到服务器的公钥。
1.客户端拿到服务器公钥之后先发送一个随机串到服务器，然服务器进行用服务器的私钥签名，并且返回
2.客户端用服务器公钥验证签名，发现果然能验证通过，于是确认这就是正确的服务器公钥。
3.客户端生成一个对称加***，服务器公钥加密，并且发送给服务器。这个过程是安全的。
4服务器收到对称**加密报文。用私钥进行解密，于是get到客户端发来的对称加密的**，于是愉快的开始了通信。
6：http版本比较
HTTP 1.1 版本新特性：
默认持久连接：
减少tcp连接的重复建立和断开。节省通信量，只要客户端和服务端任意一端没有明确的断开TCP连接，就可以发送多次HTTP请求。在一次建立的过程中，一次http请求，一次http响应，轮流交替执行。传统（短连接）要是请求一个包含多张图片的html时。获取每次图片都需要进行一次tcp的连接和断开，而现在（长连接）在一个连接过程中，请求图片1 ，图片1响应，请求图片2，图片2响应..直至获取所有资源后断开连接。
管线化：
在持久连接的基础上，请求过后不必等待响应，可以继续发送下一个请求。请求图1，请求图2，图1响应，图2响应。
断点续传原理：
其原理是：客户端记录下当前的下载进度，并在需要续传时通知服务器本次需要下载的内容片断.一个简单的断点续传实现如下：（HTTP1.1协议中定义了断点续传相关的属性，如Content-Range）当客户端下载一个1024K文件，下载到500k时网络中断,当客户端请求续传时，客户端需要在http头中声明本次需要续传的片断，如下：
Range: bytes=500000——这个头通知服务器从文件的500k位置开始传文件,服务器收到断点续传请求后，从文件的500k位置开始传输文件，并在http头开始增加Content-Range:bytes=500000-1024000
HTTP2.0新特性：
1、采用二进制格式传输数据，而非http1.1文本格式，二进制格式在协议的解析和优化扩展上带来了跟多的优势和可能。HTTP/2.0 将报文分成 HEADERS 帧和 DATA 帧，它们都是二进制格式的。
2、对消息头采用Hpack进行压缩传输，能够节省消息头占用的网络流量，http1.1每次请求，都会携带大量冗余的头信息，浪费了很多宽带资源。 要求客户端和服务器同时维护和更新一个包含之前见过的首部字段表，从而避免了重复传输。不仅如此，HTTP/2.0 也使用 Huffman 编码对首部字段进行压缩。
3、异步连接多路复用，HTTP/1.1 试过用流水线(pipelining)来解决这个问题, 但是效果并不理想(数据量较大或者速度较慢的响应, 会阻碍排在他后面的请求). 此外, 由于网络媒介(intermediary )和服务器不能很好的支持流水线, 导致部署起来困难重重。而多路传输(Multiplexing)能很好的解决这些问题, 因为它能同时处理多个消息的请求和响应; 甚至可以在传输过程中将一个消息跟另外一个掺杂在一起。在通信过程中，只会有一个 TCP 连接存在，它承载了任意数量的双向数据流（Stream）。
一个数据流都有一个唯一标识符和可选的优先级信息，用于承载双向信息。
消息（Message）是与逻辑请求或响应对应的完整的一系列帧。
帧（Frame）是最小的通信单位，来自不同数据流的帧可以交错发送，然后再根据每个帧头的数据流标识符重新组装。
4、Server Push，HTTP/2.0 在客户端请求一个资源时，会把相关的资源一起发送给客户端，客户端就不需要再次发起请求了。例如客户端请求 page.html 页面，服务端就把 script.js 和 style.css 等与之相关的资源一起发给客户端。
7：cookie与session
Cookie和session的区别：
1：cookie是存储在客户端，session存储在服务端。
2：cookie 与session都有TTL，可以通过redis等进行持久化
3：cookie是不安全的，别人可以分析本地文件进行cookie欺骗。因此登录信息一般是存储到session，其它信息存储到cookie。可以设置cookie的setSecure（true）让cookie只在https或者ssl协议下面传输。
4：session存储到服务器，到一段时间内访问较大的时候，会增加服务器压力。因此从安全性能选择session，从服务器性能选择cookie。
使用 Session 维护用户登录状态的过程如下：
用户进行登录时，用户提交包含用户名和密码的表单，放入 HTTP 请求报文中；
服务器验证该用户名和密码，如果正确则把用户信息存储到 Redis 中，它在 Redis 中的 Key 称为 Session ID；
服务器返回的响应报文的 Set-Cookie 首部字段包含了这个 Session ID，客户端收到响应报文之后将该 Cookie 值存入浏览器中；
客户端之后对同一个服务器进行请求时会包含该 Cookie 值，服务器收到之后提取出 Session ID，从 Redis 中取出用户信息，继续之前的业务操作。
Token认证机制：
①认证成功后，会对当前用户数据进行加密，生成一个加密字符串token，返还给客户端（服务器端并不进行保存）
②浏览器会将接收到的token值存储在Local Storage中，（通过js代码写入Local Storage，通过js获取，并不会像cookie一样自动携带）
③再次访问时服务器端对token值的处理：服务器对浏览器传来的token值进行解密，解密完成后进行用户数据的查询，如果查询成功，则通过认证，实现状态保持，所以，即时有了多台服务器，服务器也只是做了token的解密和用户数据的查询，它不需要在服务端去保留用户的认证信息或者会话信息，这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录了，这就为应用的扩展提供了便利，解决了session扩展性的弊端。
Cookie的跨域问题：
将web系统应用的所有子系统部署在同一个顶级域名下，通过设置cookie的setDomain方法实现。
Cookie禁掉的问题：
但是当我们完全禁掉浏览器的cookie的时候，无法使用 Cookie 来保存用户信息，只能使用 Session，除此之外，不能再将 Session ID 存放到 Cookie 中。此时有2种解决方式， 一是url重写，缺点
整个站点中不能有纯静态页面，因为纯静态页面session id 将无法继续传到下一页面
二是表单提交一个隐藏字段，缺点
不适用<a>标签这种直接跳转的非表单的情况
8：get和post区别
(1). 从功能上讲，GET一般用来从服务器上获取资源，POST一般用来更新服务器上的资源；
(2). 从REST服务角度上说，GET是幂等的，即读取同一个资源，总是得到相同的数据，而POST不是幂等的，因为每次请求对资源的改变并不是相同的；进一步地，GET不会改变服务器上的资源，而POST会对服务器资源进行改变；
(3). 从请求参数形式上看，GET请求的数据会附在URL之后，即将请求数据放置在HTTP报文的请求头中，以?分割URL和传输数据，参数之间以&相连。特别地，如果数据是英文字母/数字，原样发送；否则，会将其编码为 application/x-www-form-urlencoded MIME字符串(如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX为该符号以16进制表示的ASCII)；而POST请求会把提交的数据则放置在是HTTP请求报文的请求体中。
(4). 就安全性而言，POST的安全性要比GET的安全性高，因为GET请求提交的数据将明文出现在URL上，而且POST请求参数则被包装到请求体中，相对更安全，但不是绝对安全，因为照样可以通过一些抓包工具（Fiddler）查看。
(5). 从请求的大小看，GET请求的长度受限于浏览器或服务器对URL长度的限制，允许发送的数据量比较小，而POST请求则是没有大小限制的。
三：动态主机配置协议
动态主机配置协议：
DHCP (Dynamic Host Configuration Protocol) 提供了即插即用的连网方式，用户不再需要手动配置 IP 地址等信息。DHCP配置的内容不仅是IP地址，还包括子网掩码、网关IP地址。
DHCP 工作过程如下：
客户端发送 Discover 报文。DHCP 客户机以广播方式发送 DHCPdiscover 发现信息来寻找 DHCP 服务器，即向地址 255.255.255.255 发送特定的广播信息。网络上每一台安装了 TCP/IP 协议的 主机都会接收到这种广播信息，但只有 DHCP 服务器才会做出响应。如果客户端和 DHCP 服务器不在同一个子网，就需要使用中继代理（中继代理收到主机以广播形式发送的discovery报文后，就以单播的形式向dhcp服务器转发此报文）。
DHCP 服务器收到 Discover 报文之后，发送 Offer 报文给客户端，该报文包含了客户端所需要的信息。因为客户端可能收到多个 DHCP 服务器提供的信息，因此客户端需要进行选择。
DHCP客户机选择某台DHCP服务器提供的IP地址的阶段（DHCPrequest）。如果有多台 DHCP服务器向DHCP客户机发来的DHCPoffer提供信息，则DHCP客户机只接受第一个收到的DHCPoffer提供信息，然后它就 以广播方式回答一个DHCPrequest 请求信息，该信息中包含向它所选定的DHCP服务器请求IP地址的内容。之所以要以广播方式回答，是为了通知所有的DHCP服务器，他将选择某台DHCP服务器所提供的IP地址。
DHCP服务器发送Ack报文，表示客户端此时可以使用提供给它的信息。
四：电子邮件协议
一个电子邮件系统由三部分组成：用户代理、邮件服务器以及邮件协议。
邮件协议包含发送协议和读取协议，发送协议常用 SMTP，读取协议常用 POP3 和 IMAP。
五：文件传送协议
FTP 使用 TCP 进行连接，它需要两个连接来传送一个文件：
控制连接：服务器打开端口号 21 等待客户端的连接，客户端主动建立连接后，使用这个连接将客户端的命令传送给服务器，并传回服务器的应答。
数据连接：用来传送一个文件数据。
根据数据连接是否是服务器端主动建立，FTP 有主动和被动两种模式：
主动模式：服务器端主动建立数据连接，其中服务器端的端口号为 20，客户端的端口号随机，但是必须大于 1024，因为 0~1023 是熟知端口号。
被动模式：客户端主动建立数据连接，其中客户端的端口号由客户端自己指定，服务器端的端口号随机。
主动模式要求客户端开放端口号给服务器端，需要去配置客户端的防火墙。被动模式只需要服务器端开放端口号即可，无需客户端配置防火墙。但是被动模式会导致服务器端的安全性减弱，因为开放了过多的端口号。
六：websocket
Socket是应用层与TCP/IP协议族通信的中间软件抽象层，它是一组接口。在设计模式中，Socket其实就是一个门面模式，它把复杂的TCP/IP协议族隐藏在Socket接口后面，对用户来说，一组简单的接口就是全部，让Socket去组织数据，以符合指定的协议。当两台主机通信时，必须通过Socket连接，Socket则利用TCP/IP协议建立TCP连接。TCP连接则更依靠于底层的IP协议，IP协议的连接则依赖于链路层等更低层次。HTTP协议是非持久化的，单向的网络协议，在建立连接后只允许浏览器向服务器发出请求后，服务器才能返回相应的数据。当需要即时通讯时，通过轮询在特定的时间间隔（如1秒），由浏览器向服务器发送Request请求，然后将最新的数据返回给浏览器。这样的方法最明显的缺点就是需要不断的发送请求，而且通常HTTP request的Header是非常长的，为了传输一个很小的数据 需要付出巨大的代价，是很不合算的，占用了很多的宽带。
WebSocket是HTML5一种新的协议。它实现了浏览器与服务器全双工通信，能更好的节省服务器资源和带宽并达到实时通讯，它建立在TCP之上，同HTTP一样通过TCP来传输数据，但是它和 HTTP 最大不同是：
WebSocket是一种双向通信协议，在建立连接后，WebSocket服务器和Browser/Client Agent都能主动的向对方发送或接收数据，就像Socket一样；
WebSocket需要类似TCP的客户端和服务器端通过握手连接，连接成功后才能相互通信。
第一步：握手请求，请求头中用upgrade：websocket字段告知服务端通信协议发生变化，
第二步：握手响应，响应行返回状态码101 Switching Protocols
WebSocket是类似Socket的TCP长连接的通讯模式，一旦WebSocket连接建立后，后续数据都以帧序列的形式传输。在客户端断开 WebSocket 连接或 Server 端断掉连接前，不需要客户端和服务端重新发起连接请求。在海量并发及客户端与服务器交互负载流量大的情况下，极大的节省了网络带宽资源的消耗，有明显的性能优势，且客户端发送和接受消息是在同一个持久连接上发起，实时性优势明显。