ISO/OSI七层参考模型
1. 应用层：为应用程序或用户请求提供各种请求服务。OSI参考模型最高层，也是最靠近用户的一层，为计算机用户、各种应用程序以及网络提供接口，也为用户直接提供各种网络服务。
2. 表示层：数据编码、格式转换、数据加密。提供各种用于应用层数据的编码和转换功能,确保一个系统的应用层发送的数据能被另一个系统的应用层识别。如果必要，该层可提供一种标准表示形式，用于将计算机内部的多种数据格式转换成通信中采用的标准表示形式。数据压缩和加密也是表示层可提供的转换功能之一。
3. 会话层：创建、管理和维护会话。接收来自传输层的数据，负责建立、管理和终止表示层实体之间的通信会话，支持它们之间的数据交换。该层的通信由不同设备中的应用程序之间的服务请求和响应组成。
4. 传输层：数据通信。建立主机端到端的链接，为会话层和网络层提供端到端可靠的和透明的数据传输服务，确保数据能完整的传输到网络层。
5. 网络层：IP选址及路由选择。通过路由选择算法，为报文或通信子网选择最适当的路径。控制数据链路层与传输层之间的信息转发，建立、维持和终止网络的连接。数据链路层的数据在这一层被转换为数据包，然后通过路径选择、分段组合、顺序、进/出路由等控制，将信息从一个网络设备传送到另一个网络设备。
6. 数据链路层：提供介质访问和链路管理。接收来自物理层的位流形式的数据，封装成帧，传送到网络层；将网络层的数据帧，拆装为位流形式的数据转发到物理层；负责建立和管理节点间的链路，通过各种控制协议，将有差错的物理信道变为无差错的、能可靠传输数据帧的数据链路。
7. 物理层：管理通信设备和网络媒体之间的互联互通。传输介质为数据链路层提供物理连接，实现比特流的透明传输。实现相邻计算机节点之间比特流的透明传送，屏蔽具体传输介质和物理设备的差异。
DNS服务器工作过程
第一步，客户端向本地DNS服务器发送解析请求 第二步，本地DNS如有相应记录会直接返回结果给客户端，如没有就向DNS根服务器发送请求(迭代or递归) 第三步, DSN根服务器接收到请求，返回给本地服务器一个所查询域的主域名服务器的地址 第四步，本地dns服务器再向返回的主域名服务器地址发送查询请求 第五步，主域名服务器如有记录就返回结果，没有的话返回相关的下级域名服务器地址 第六步，本地DNS服务器继续向接收到的地址进行查询请求 第七步，下级域名服务器有相应记录，返回结果 第八步，本地dns服务器将收到的返回地址发给客户端，同时写入自己的缓存，以便下次查询
RFC 768（UDP）
介绍
用户数据报协议（UDP）的定义是为了在一组互连的计算机网络环境中提供数据包交换计算机通信的数据报模式。此协议假定将IP协议作为基础协议。
该协议为程序程序提供了一种以最少的协议机制将消息发送到其他程序的过程。该协议是面向事务的，无法保证传输和复制保护。需要有序且可靠传输数据流的应用程序应当使用传输控制协议（TCP）
格式
0 7 8 15 16 23 24 31
+--------+--------+--------+--------+
| 源端口 | 目的端口 |
+--------+--------+--------+--------+
| | |
| 长度 | 校验和 |
+--------+--------+--------+--------+
|
| 数据 ...
+---------------- ...
报文头格式
字段
源端口：源端口是一个可选字段，当有意义时，表明发送数据的进程的端口，也可以在没有其他信息的情况下假定该端口是回复的地址端口。如果源端口未被使用则插入0代替
目的端口：目的端口意味着在数据报中有一个特别的互联网地址
长度：长度是指这个用户数据报的字节长度，以八个字节为单位，包括了报文头和数据（这意味着长度的最小值为8个字节）
校验和：校验和是来自IP报头和UDP报头信息的一个伪首部的反码运算求和的16位反码，在UDP报头中，数据部分要用0值个字节填充结束（如果有必要的话）以使数据是16位的倍数。
伪首部实际上不存在的，只是概念性的加在UDP头部的最前面，其包含源地址，目的地址，协议，和UDP长度。这个信息保证了数据报能够正确路由。这个校验和过程也同样在TCP中使用。
0 7 8 15 16 23 24 31
+--------+--------+--------+--------+
| 源地址 |
+--------+--------+--------+--------+
| 目的地址 |
+--------+--------+--------+--------+
| 0 | 协议 | UDP 长度 |
+--------+--------+--------+--------+
如果计算出的校验和是0，它以全1进行传输（相当于用反码运算）。一个全0的可传输的校验和的值意味着它的发送者没有进行校验（对调试或更高级的协议则无需关心）
用户接口
一个用户接口应该可以创建新的接收端口，在返回字节数据和一个指示源端口和源地址的接收端口上进行接收操作，允许发送一个数据报的操作，也允许发送指定源端口，目的端口，源地址，目的地址的数据。
此UDP模块必须能够从Internet报头确定源和目的地址以及协议字段。一个可能的UDP/IP接口将响应接收操作，返回包括所有Internet报头的整个Internet数据包。这样的接口还将允许UDP将完整的Internet数据报（带有标头）传递给IP发送。IP将验证某些字段的一致性，并计算Internet报头的校验和。
协议应用
该协议的主要用途是Internet域名服务和简单文件传输
协议编号
在Internet协议中使用时，这是协议17（八进制21）
HTTP的进化历程(1.0 2.0 3.0)
缓存处理：HTTP/1.0 使用
Pragma:no-cache + Last-Modified/If-Modified-Since来作为缓存判断的标准；HTTP/1.1 引入了更多的缓存控制策略：Cache-Control、Etag/If-None-Match等。错误状态管理：HTTP/1.1新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
范围请求：HTTP/1.1在请求头引入了
range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接，支持断点续传。Host头：HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。有了Host字段，就可以将请求发往同一台服务器上的不同网站，为虚拟主机的兴起打下了基础。
持久连接：HTTP/1.1 最大的变化就是引入了持久连接（persistent connection），在HTTP/1.1中默认开启
Connection: keep-alive，即TCP连接默认不关闭，可以被多个请求复用。
客户端和服务器发现对方一段时间没有活动，就可以主动关闭连接。不过，规范的做法是，客户端在最后一个请求时，发送Connection: close，明确要求服务器关闭TCP连接。客户端和服务器发现对方一段时间没有活动，就可以主动关闭连接。不过，规范的做法是，客户端在最后一个请求时，发送Connection: close，明确要求服务器关闭TCP连接。
- 管道机制：HTTP/1.1中引入了管道机制（pipelining）,即在同一个TCP连接中，客户端可以同时发送多个请求。
TCP三次握手，两次或四次?
第一次握手
第 1 次握手建立连接时，客户端向服务器发送 SYN 报文（SEQ=x，SYN=1），并进入 SYN_SENT 状态，等待服务器确认，如图所示。
第二次握手
第 2 次握手实际上是分两部分来完成的，即 SYN+ACK（请求和确认）报文。
- 服务器收到了客户端的请求，向客户端回复一个确认信息（ACK=x+1）。
- 服务器再向客户端发送一个 SYN 包（SEQ=y）建立连接的请求，此时服务器进入 SYN_RECV 状态，如图所示。
第三次握手
第 3 次握手，是客户端收到服务器的回复（SYN+ACK 报文）。此时，客户端也要向服务器发送确认包（ACK）。此包发送完毕客户端和服务器进入 ESTABLISHED 状态，完成 3 次握手，如图所示。
为什么不是两次或四次？
这个问题的本质是, 信道不可靠, 但是通信双发需要就某个问题达成一致. 而要解决这个问题, 无论你在消息中包含什么信息, 三次通信是理论上的最小值. 所以三次握手不是TCP本身的要求, 而是为了满足"在不可靠信道上可靠地传输信息"这一需求所导致的. 请注意这里的本质需求,信道不可靠, 数据传输要可靠. 三次达到了, 那后面你想接着握手也好, 发数据也好, 跟进行可靠信息传输的需求就没关系了. 因此,如果信道是可靠的, 即无论什么时候发出消息, 对方一定能收到, 或者你不关心是否要保证对方收到你的消息, 那就能像UDP那样直接发送消息就可以了
两次握手的情况：
假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。但如果client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据,但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。
采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认,server由于收不到确认，就知道client并没有要求建立连接。
四次或N次：
建立连接的时间太长，效果也会大打折扣。所以3次只是折中方案（为了达到在不可靠信道上可靠地传输信息这一要求），只要保证信道的可靠性就可以向UDP那样直接发送消息