网络原理之备考总结传输层～应用层（相关考点总结）
离考试还有一周左右的时间了！休息好，才记得住！适当愉悦自己！
－－－－坚持！
如题2017年10月
这就比较综合了，也符合网络知识核心内容----协议
分析:从题目一步步答就行
应用层：
浏览器用了HTTP协议：客户端浏览器与web服务器之间的应用层通讯协议
网站地址DNS：域名解析服务将域名解析为IP地址。
传输层：
TCP:用于在不可靠因特网上提供可靠的，端到端字节流通信协议。
网络层
ICMP:提供差错报告和请求应答服务
ARP：将IP地址转为以太网48位MAC地址
IP:提供不可靠、无连接数据报传输机制
网络接口层：
IEEE802.3一种局域网标准协议，使用CSMA/CD为以太网提供介质访问控制方法。
续：
TCP/IP协议是Internet最基本的协议、Internet国际互联网络的基础，由网络层的IP协议和传输层的TCP协议组成。通俗而言：TCP负责发现传输的问题，一有问题就发出信号，要求重新传输，直到所有数据安全正确地传输到目的地。而IP是给因特网的每一台联网设备规定一个地址。
如题：2017年10月
解：传输层的IP＋端口号只能代表一个SOCKET，这样来区分不同服务。
通过 IP 地址、端口号、协议号进行通信识别:
仅凭目标端口号识别某一个通信是远远不够的。需要通过源IP地址，目的IP地址，协议号，源端口号和目的端口号这五个元素来识别一次通信。
4）传输层（Transport Layer）
第一个端到端，即主机到主机的层次。传输层负责将上层数据分段并提供端到端的、可靠的或不可靠的传输。此外，传输层还要处理端到端的差错控制和流量控制问题。在这一层，信息传送的协议数据单元称为段或报文。
网络层只是根据网络地址将源结点发出的数据包传送到目的结点（因为数据链路层, 网络层这两层的数据传输都是不可靠的, 尽最大能力交付的 ），而传输层则负责将数据可靠地传送到相应的端口。
相关的重点：
1> 传输层负责将上层数据分段并提供端到端的、可靠的或不可靠的传输以及端到端的差错控制和流量控制问题；
2> 包含的主要协议：TCP协议（Transmission Control Protocol，传输控制协议）、UDP协议（User Datagram Protocol，用户数据报协议）；
3> 重要设备：网关。
用户数据报协议UDP
UDP用户数据报协议，是面向无连接的通讯协议，UDP数据包括目的端口号和源端口号信息，由于通讯不需要连接，所以可以实现广播发送。UDP通讯时不需要接收方确认，属于不可靠的传输，可能会出现丢包现象，实际应用中要求程序员编程验证。
UDP与TCP位于同一层，但它不管数据包的顺序、错误或重发。因此，UDP不被应用于那些使用虚电路的面向连接的服务，UDP主要用于那些面向查询---应答的服务，例如NFS。相对于FTP或Telnet，这些服务需要交换的信息量较小。
UDP主要特点 :
- 无连接
- 尽最大努力交付
- 面向报文 : 应用层交下来的报文直接加上UDP头部就往IP层扔, 不合并也不拆分
- 没有拥塞控制
- 支持一对一, 一对多, 多对一和多对多的交互通信
- 首部开销小, 只有8个字节
UDP首部格式
- 源端口 : 源端口号. 在需要对方回信时选用, 不需要则全0
- 目的端口 : 目的端口号. 这在终点交付报文时必须要使用到
- 长度 : UDP数据报的长度, 最小值为8(仅有首部)
- 检验和 : 与IP数据报只检验首部不同的是, UDP需要把首部和数据部分一起检验
传输控制协议TCP
TCP主要特点 :
- 面向连接的运输层协议
- 每一条TCP连接只能有2个端点, TCP是点对点的
- 提供可靠交付
- 全双工通信
- 面向字节流
如题：
分析：TCP只支持点到点，所以才可以做到可靠。
TCP字节流
TCP的连接
TCP连接的端点叫套接字(socket)
socket = (IP地址 : 端口号)
每一条TCP连接唯一地被通信两端的两个端点(socket)所确定. 即 :TCP连接 ::= {socket1, socket2} = {(IP1 : port1), (IP2 : port2)}
TCP报文段的首部
TCP报文段的首部
- 源端口和目的端口 : 同UDP端口作用
- 序号 : 本报文段的数据的第一个字节的序号
- 确认号 : 期望收到对方下一个报文段的第一个数据字节的序号
若确认号 = N, 则表明 : 到序号N-1为止的所有数据都已正常收到 - 数据偏移 : TCP报文段的首部长度
- 保留 : 以后用, 目前为0
- 紧急URG : 若URG = 1时, 说明紧急指针字段有效, 告诉系统这是紧急数据, 应尽快传送. 例如突然要中断传送
- 确认ACK : ACK = 1时确认号才有效, ACK = 0时确认号无效. TCP规定, 连接建立后所有传送的报文段都必须把ACK置1
- 推送PSH : 若PSH = 1, 则接收方收到报文段之后不再等到整个缓存满而是直接向上交付
- 复位RST : 当RST = 1, 说明TCP连接有严重错误, 必须释放连接再重连
- 同步SYN : 在连接建立时用来同步序号. 当SYN = 1, ACK = 0时表明这是一个连接请求报文段, 对方若同意建立连接, 则在响应的报文段中置SYN = 1, ACK = 1
- 终止FIN : 当FIN = 1, 表明此报文段的发送方数据已发送完毕, 并要求释放连接
- 窗口 : 告诉对方 : 从本报文段首部中的确认号算起, 接收方目前允许对方发送的数据量. 这是作为接收方让发送方设置其发送窗口的依据
- 检验和 : 同UDP, 检验首部和数据部分
- 紧急指针 : 当URG = 1时有效, 指出紧急数据的末尾在报文段的位置
- 选项 : 最大可40字节, 没有则为0
最大报文段长度MSS(Maximum Segment Size) : 每一个TCP报文段中数据字段的最大长度, 若不填写则为默认的536字节.
窗口
TCP中很重要的一个概念, 那就是窗口(发送窗口和接收窗口)
由于停止等待协议非常低效, 于是衍生出窗口这一概念. 上图为发送方维持的发送窗口, 位于发送窗口的5个分组都可以连续发送出去而不需要等待对方的确认. 每收到一个确认, 就把发送窗口前移一个分组的位置. 这大大提高了信道利用率!
接收方不必发送每个分组的确认报文, 而是采用累积确认的方式. 也就是说, 对按序到达的最后一个分组发送确认报文.
超时重传
如果发送方等待一段时间后, 还是没收到 ACK 确认报文, 就会启动超时重传. 这个等待的时间为重传超时时间(RTO, Retransmission TimeOut).然而, RTO 的值不是固定的, 这个时间总是略大于连接往返时间(RTT，Round Trip Time). 假设报文发送过去需要5秒, 对方收到后发送确认报文回来也需要5秒, 那么RTT就为10秒, 那这RTO就要比10秒要略大一些. 那么超过RTO之后还没有收到确认报文就认为报文丢失了, 就要重传.
流量控制
利用滑动窗口和报文段的发送时机来进行流量控制.
拥塞控制
发送方维持一个拥塞窗口cwnd, 发送窗口 = 拥塞窗口.
慢开始 : cwnd = 1, 然后每经过一个传输轮次就翻倍拥塞避免 : 让cwnd缓慢增大, 每经过一个传输轮次就+1慢开始门限ssthresh :
当cwnd < ssthresh, 使用慢开始算法
当cwnd > ssthresh, 使用拥塞避免算法
当cwnd = ssthresh, 随意
拥塞控制
只要判断网络出现拥塞, 把ssthresh设为当前发送拥塞窗口的一半(不能小于2), 并把cwnd设为1, 重新执行慢开始算法.
除了慢开始和拥塞避免算法外, 还有一组快重传和快恢复算法 :
快重传 : 一连收到三个重复确认, 发送端马上重传（也就是说发送端对于发送超时和三次重复确认，都认为是报文丢失）快恢复 : 当发送方一连收到三个重复确认时, ssthresh减半, cwnd设为ssthresh.（只针对三次重复确认情形，拥塞不是很严重）
TCP三次握手
TCP三次握手建立连接和四次挥手断开连接是面试爱问的知识点.
Q : 为什么要三次握手, 两次不可以吗?
A : 试想一下, A第一次发送请求连接, 但是在网络某节点滞留了, A超时重传, 然后这一次一切正常, A跟B就愉快地进行数据传输了. 等到连接释放了以后, 那个迷失了的连接请求突然到了B那, 如果是两次握手的话, B发送确认, 它们就算是建立起了连接了. 事实上A并不会理会这个确认, 因为我压根没有要传数据啊. 但是B却傻傻地以为有数据要来, 苦苦等待. 结果就是造成资源的浪费.
更加接地气的解释就是 : A打电话给B
第一次握手 : 你好, 我是A, 你能听到我说话吗
第二次握手 : 听到了, 我是B, 你能听到我说话吗
第三次握手 : 听到了, 我们可以开始聊天了
三次握手其实就是为了检测双方的发送和接收能力是否正常, 你说呢?TCP四次挥手
Q : 为什么要四次挥手, 而不是两次, 三次?
A :
首先, 由于TCP的全双工通信, 双方都能作为数据发送方. A想要关闭连接, 必须要等数据都发送完毕, 才发送FIN给B. (此时A处于半关闭状态)
然后, B发送确认ACK, 并且B此时如果要发送数据, 就发送(例如做一些释放前的处理)
再者, B发送完数据之后, 发送FIN给A. (此时B处于半关闭状态)
然后, A发送ACK, 进入TIME-WAIT状态
最后, 经过2MSL时间后没有收到B传来的报文, 则确定B收到了ACK了. (此时A, B才算是处于完全关闭状态)
PS : 仔细分析以上步骤就知道为什么不能少于四次挥手了.
Q : 为什么要等待2MSL(Maximum Segment Lifetime)时间, 才从TIME_WAIT到CLOSED？
A : 在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。
更加接地气的解释 :
第一次挥手 : A告诉B, 我没数据发了, 准备关闭连接了, 你要发送数据吗
第二次挥手 : B发送最后的数据
第三次挥手 : B告诉A, 我也要关闭连接了
第四次挥手 : A告诉B你可以关闭了, 我这边也关闭了使用TCP的协议：FTP（文件传输协议）、Telnet（远程登录协议）、SMTP（简单邮件传输协议）、POP3（和SMTP相对，用于接收邮件）、HTTP协议等。
5）会话层
会话层管理主机之间的会话进程，即负责建立、管理、终止进程之间的会话。会话层还利用在数据中插入校验点来实现数据的同步。
6）表示层
表示层对上层数据或信息进行变换以保证一个主机应用层信息可以被另一个主机的应用程序理解。表示层的数据转换包括数据的加密、压缩、格式转换等。
7）应用层
为操作系统或网络应用程序提供访问网络服务的接口。
会话层、表示层和应用层重点：
1> 数据传输基本单位为报文；
2> 包含的主要协议：FTP（文件传送协议）、Telnet（远程登录协议）、DNS（域名解析协议）、SMTP（邮件传送协议），POP3协议（邮局协议），HTTP协议（Hyper Text Transfer Protocol）。
如题：2017年10月
域名系统(DNS, Domain Name System)
DNS 能将域名(例如, www.jianshu.com)解析成IP地址.
域名服务器分类
- 根域名服务器 : 最高层次的域名服务器
- 顶级域名服务器 : 如其名
- 权限域名服务器 : 负责一个区的应服务器
- 本地域名服务器 : 主机发送DNS查询请求就是发给它
- 主机向本地域名服务器的查询一般都是采用递归查询
- 本地域名服务器向根域名服务器的查询通常是采用迭代查询
递归查询 : B问A广州怎么去, A不知道, A就问C, C不知道就问D...直到知道了再一层一层转告直到A告诉B. 迭代查询 : B问A广州怎么去, A不知道, A就告诉你可以去问C, 然后B就去问C, C不知道, C就告诉你可以去问D, 然后B就去问D...直到B知道为止
DNS查询例子 : 域名为x.tom.com的主机想知道y.jerry.com的IP地址
- 主机x.tom.com先向本地域名服务器dns.tom.com进行递归查询
- 本地域名服务器采用迭代查询. 它先问一个根域名服务器
- 根域名服务器告诉它, 你去问顶级域名服务器dns.com
- 本地域名服务器问顶级域名服务器dns.com
- 顶级域名服务器告诉它, 你去问权限域名服务器dns.jerry.com
- 本地域名服务器问权限域名服务器dns.jerry.com
- 权限域名服务器dns.jerry.com告诉它所查询的主机的IP地址
- 本地域名服务器把查询结果告诉主机x.tom.com
PS : 该查询使用UDP, 并且为了提高DNS查询效率, 每个域名服务器都使用高速缓存.
URL
URL的格式 : <协议>://<主机>:<端口>/<路径>, 端口和路径有时可省略.
使用HTTP协议的URL : http://<主机>:<端口>/<路径>, HTTP默认端口号是80
HTTP协议
HTTP是面向事务的, 即它传输的数据是一个整体, 要么全部收到, 要么全部收不到.
万维网的工作过程
每一次HTTP请求就需要建立一次TCP连接和释放TCP连接.
HTTP是无连接, 无状态的. 每一次请求都是作为一次新请求.
HTTP/1.0 缺点 : 无连接, 每一次请求都要重新建立TCP连接, 所以每一次HTTP请求都要花费2倍RTT时间(一次TCP请求, 一次HTTP请求)
HTTP/1.1 : 使用持续连接, 即保持TCP连接一段时间.
HTTP/1.1持续工作的两种工作方式 : 非流水线方式和流水线方式
非流水线方式 : 收到一个请求的响应再发下一个请求, 效率低, 浪费资源
流水线方式 : 能够同时发送多个请求, 效率高HTTP的GET和POST
GET 请求通常用于查询、获取数据，而 POST 请求则用于发送数据
GET 请求的参数在URL中, 因此绝不能用GET请求传输敏感数据, 而POST 请求的参数在请求头中, 安全性略高于GET请求
ps : POST请求的数据也是以明文的形式存放在请求头中, 因此也不安全
注：
HTTP 协议包括哪些请求？
GET：请求读取由URL所标志的信息。
POST：给服务器添加信息（如注释）。
PUT：在给定的URL下存储一个文档。
DELETE：删除给定的URL所标志的资源。
HTTP 中， POST 与 GET 的区别
1）Get是从服务器上获取数据，Post是向服务器传送数据。
2）Get是把参数数据队列加到提交表单的Action属性所指向的URL中，值和表单内各个字段一一对应，在URL中可以看到。
3）Get传送的数据量小，不能大于2KB；Post传送的数据量较大，一般被默认为不受限制。
4）根据HTTP规范，GET用于信息获取，而且应该是安全的和幂等的。
I. 所谓 安全的 意味着该操作用于获取信息而非修改信息。换句话说，GET请求一般不应产生副作用。就是说，它仅仅是获取资源信息，就像数据库查询一样，不会修改，增加数据，不会影响资源的状态。
II. 幂等 的意味着对同一URL的多个请求应该返回同样的结果。
在浏览器中输入 www.baidu.com 后执行的全部过程
现在假设如果我们在客户端（客户端）浏览器中输入http://www.baidu.com,而baidu.com为要访问的服务器（服务器），下面详细分析客户端为了访问服务器而执行的一系列关于协议的操作：
1）客户端浏览器通过DNS解析到www.baidu.com的IP地址220.181.27.48，通过这个IP地址找到客户端到服务器的路径。客户端浏览器发起一个HTTP会话到220.161.27.48，然后通过TCP进行封装数据包，输入到网络层。
2）在客户端的传输层，把HTTP会话请求分成报文段，添加源和目的端口，如服务器使用80端口监听客户端的请求，客户端由系统随机选择一个端口如5000，与服务器进行交换，服务器把相应的请求返回给客户端的5000端口。然后使用IP层的IP地址查找目的端。
3）客户端的网络层不用关系应用层或者传输层的东西，主要做的是通过查找路由表确定如何到达服务器，期间可能经过多个路由器，这些都是由路由器来完成的工作，不作过多的描述，无非就是通过查找路由表决定通过那个路径到达服务器。
4）客户端的链路层，包通过链路层发送到路由器，通过邻居协议查找给定IP地址的MAC地址，然后发送ARP请求查找目的地址，如果得到回应后就可以使用ARP的请求应答交换的IP数据包现在就可以传输了，然后发送IP数据包到达服务器的地址。
Cookie
万维网使用Cookie来跟踪用户, 表示HTTP服务器和用户之间传递的状态信息.
Cookie工作原理 :
1. 用户浏览某网站, 该网站的服务器为用户产生一个唯一的识别码, 并以此为索引在服务器后端数据库中产生一个项目
2. 返回给用户的HTTP响应报文中添加一条 "Set-cookie", 值为该识别码, 如123
3. 用户的浏览器将该cookie保存起来, 在用于继续浏览该网站时发送的每一个HTTP请求都会有一行 Cookie: 123
于是, 这个网站就知道Cookie为123的这个用户做了什么, 为这个用户维护一个独立的列表(如购物车)当然, Cookie是把双刃剑, 方便的同时也带有危险性, 例如隐私泄露等, 用户可以自行决定是否使用Cookie
Session（对话）
Cookie是保存在客户端上的, 而Session是保存在服务器中. 当服务器收到用户发出的Cookie时, 会根据Cookie中的SessionID来查找对应的Session, 如没有则会生成一个新的SessionID返回给用户
总而言之, Cookie和Session就是同一样东西存放地方不同而已.
HTTPS
HTTPS协议
HTTPS协议在HTTP协议的基础上, 在HTTP和TCP中间加入了一层SSL/TLS加密层, 解决了HTTP不安全的问题: 冒充, 篡改, 窃听三大风险.
SSL/TLS协议是为了解决这三大风险而设计的，希望达到：
（1） 所有信息都是加密传播，第三方无法窃听。
（2） 具有校验机制，一旦被篡改，通信双方会立刻发现。
（3） 配备身份证书，防止身份被冒充。
目前，应用最广泛的是TLS 1.0，接下来是SSL 3.0。但是，主流浏览器都已经实现了TLS 1.2的支持。
TLS 1.0通常被标示为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3。
基本的运行过程
SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。
但是，这里有两个问题。
（1）如何保证公钥不被篡改？
解决方法：将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。
（2）公钥加密计算量太大，如何减少耗用的时间？
解决方法：每一次对话（session），客户端和服务器端都生成一个”对话密钥”（session key），用它来加密信息。由于”对话密钥”是对称加密，所以运算速度非常快，而服务器公钥只用于加密”对话密钥”本身，这样就减少了加密运算的消耗时间。
因此，SSL/TLS协议的基本过程是这样的：
（1） 客户端向服务器端索要并验证公钥。
（2） 双方协商生成”对话密钥”。
（3） 双方采用”对话密钥”进行加密通信。
上面过程的前两步，又称为”握手阶段”（handshake）。
握手阶段的详细过程
”握手阶段”的所有通信都是明文的。
客户端发出请求（ClientHello）
首先，客户端（通常是浏览器）先向服务器发出加密通信的请求，这被叫做ClientHello请求。
在这一步，客户端主要向服务器提供以下信息。
（1） 支持的协议版本，比如TLS 1.0版。
（2） 一个客户端生成的随机数，稍后用于生成”对话密钥”。
（3） 支持的加密方法，比如RSA公钥加密。
（4） 支持的压缩方法。
这里需要注意的是，客户端发送的信息之中不包括服务器的域名。也就是说，理论上服务器只能包含一个网站，否则会分不清应该向客户端提供哪一个网站的数字证书。这就是为什么通常一台服务器只能有一张数字证书的原因。
对于虚拟主机的用户来说，这当然很不方便。2006年，TLS协议加入了一个Server Name Indication扩展，允许客户端向服务器提供它所请求的域名。
服务器回应（SeverHello）
服务器收到客户端请求后，向客户端发出回应，这叫做SeverHello。服务器的回应包含以下内容。
（1） 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
（2） 一个服务器生成的随机数，稍后用于生成”对话密钥”。
（3） 确认使用的加密方法，比如RSA公钥加密。
（4） 服务器证书。
除了上面这些信息，如果服务器需要确认客户端的身份，就会再包含一项请求，要求客户端提供”客户端证书”。比如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供USB密钥，里面就包含了一张客户端证书。
客户端回应
客户端收到服务器回应以后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。
果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下面三项信息。
（1） 一个随机数。该随机数用服务器公钥加密，防止被窃听。
（2） 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
（3） 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。
上面第一项的随机数，是整个握手阶段出现的第三个随机数，又称”pre-master key”。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把”会话密钥”。
至于为什么一定要用三个随机数，来生成”会话密钥”，dog250解释得很好：
“不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。
对于RSA密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。
pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre master secret就有可能被猜出来，那么仅适用pre master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。”
此外，如果前一步，服务器要求客户端证书，客户端会在这一步发送证书及相关信息。
服务器的最后回应
服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的”会话密钥”。然后，向客户端最后发送下面信息。
（1）编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。
至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用”会话密钥”加密内容。