网络协议篇

网络协议

当网络的边缘部分中的两个主机使用网络的核心部分的功能进行端到端的通信时，只有主机的协议栈才有运输层，而网络核心部分中的路由器在转发分组时都只用到下三层的功能。

为什么要有运输层？

IP层角度：两个主机的通信

运输层角度：两个应用进程间的通信

从运输层的角度看，通信的真正端点并不是主机而是主机中的进程。也就是说，端到端的通信是应用进程之间的通信

网络层是为主机之间提供逻辑通信，运输层是为应用进程之间提供逻辑通信

运输层对报文进行差错检测，网络层只对首部进行检验

UDP

• 无连接：发送前不需要建立连接

• 最大努力交付：不可靠交付

• 面向报文：
  对于发送方：UDP收到应用程序给的报文，直接加上首部就交给IP层
  对于接受方：IP层上传的报文，直接去掉首部就交给应用层
  

• 没有拥塞控制：网络拥塞，源主机照样发

TCP

• 面向连接：必须先建立TCP连接

• 一对一：两个端点（套接字，即IP:端口）

• 可靠交付：无差错 不丢失 不重复 按序到达

• 全双工通信：发送缓存和接受缓存

• 面向字节流：

TCP并不关心应用进程一次把多长的报文发送到TCP的缓存中，而是根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节

如果应用进程传送到TCP缓存的数据块太长，TCP就可以把它划分短一些再传送。如果应用进程一次只发来一个字节，TCP也可以等待积累有足够多的字节后再构成报文段发送出去。

UDP发送的报文长度是应用进程给出的

TCP怎么保证可靠？

1、停止等待协议
（1）发送–停止等待确认—收到确认—继续发送

​ （2）超时重传：超过一定时间没收到确认，就重传

​ （3）确认迟到或确认丢失：自动重传请求ARQ

停止等待协议传输效率太低了，采用流水线传输
2、连续ARQ协议和滑动窗口协议

连续ARQ协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。

（1）发送方： 一次性发送窗口里面的数据，每收到一个确认，窗口往前滑一个

（2）接收方：累积确认。就是对按序到达的最后一个分组发送确认，不需要每收到一个就发一次确认。

但是，若连续发送几个，一旦中间某个分组丢失了，那么接收方就只对这个分组之前的数据进行确认了，对发送方来说，丢失的分组及它后面那些都要重传。（这叫GO-back-N）

3、TCP报文段的首部格式

虽然TCP面向字节流，但传输的数据单元是报文段

TCP报文=首部+数据

首部

序号：TCP是面向字节流的，每个字节都要按顺序编号。传的是报文段，所以这个序号就是报文段第一个字节的序号。

确认号：期望收到对方下一个报文段的第一个字节的序号

数据偏移：TCP报文段的数据起始处距离TCP报文段的起始处有多远—就是首部的长度

紧急URG：该报文段紧急传送，不用排队

确认ACK：连接建立后所有传送的报文段ACK置1

推送PSH：接收方收到PSH=1的报文段，会尽快交付应用进程，不需要等到缓存满了再向上交付

复位RST：TCP连接出现严重错误，需释放连接再重建连接

同步SYN：连接建立时用来同步序号。SYN=1且ACK=0：请求连接 ； SYN=1且ACK=1：接受连接请求

终止FIN：释放连接 FIN=1：数据发送完毕，要求释放连接

窗口：允许对方给我发送多少数据量

检验和：校验

紧急指针：在URG=1下有效，指出紧急数据有多少

TCP流量控制

流量控制？：让发送方不要发太快，让接收方来得及接受

TCP的窗口单位是字节，不是报文段

这张图就表明通过滑动窗口来实现流量控制。最后rwnd=0就跟发送方说不能再发了。要等到B给它再发一次新的窗口值为止。

但是如果B给A发了一个新的窗口值，此时却丢失了，那岂不是A 和 B都一直在等待，死锁了？

解决方法：持续计时器。

A收到零窗口开始，就启动持续计时器，到点了就给B发送零窗口探测报文段

TCP拥塞控制

拥塞控制：防止过多的数据进入网络

拥塞控制和流量控制的区别

拥塞控制的方法：

慢开始、拥塞避免、快重传、快恢复

发送方弄一个拥塞窗口（cwnd），令发送窗口==拥塞窗口。

若拥塞，则拥塞窗口变小。若没拥塞，拥塞窗口变大。

1、如何知道拥塞？发送方没有按时收到应当到达的确认报文，便猜想发生了拥塞。

2、窗口如何变化？

（1） 慢开始算法： 先把拥塞窗口设置为1个MSS(最大报文段)，每收到一个报文段的确认，窗口+1，这样窗口就在翻倍扩大

（2） 设置慢开始门限ssthresh：

​ cwnd<ssthresh：慢开始算法

​ cwnd=ssthresh：慢开始、拥塞避免算法都可

​ cwnd>ssthresh：拥塞避免算法

（3）拥塞避免算法：每经过一个往返时间RTT就把发送方窗口+1，线性增长，不是加倍

（4）无论慢开始阶段还是拥塞避免阶段，一旦发现拥塞（确认没有按时到达），就把慢开始门限设置为拥塞时发送窗口的一半，然后拥塞cwnd窗口设置为1，重新开始执行慢开始算法

拥塞避免算法只是将拥塞窗口控制为线程规律增长，使得网络比较不容易发生阻塞

还有两个拥塞避免算法：快重传和快恢复

快重传：就是收到失序的报文时，就立即给发送方发送重复确认，比如下面图的接收方就是一直发送确认已收到M2，发送方连续收到3个重复确认，就立即重传，不用等到重传计时器到期。

快恢复：

（1）把慢开始门限减少为拥塞窗口的一半(预防发生拥塞)

（2）不是重新开始慢开始算法，而是执行拥塞避免算法（因为很可能不是拥塞，否则就不会有连续几个报文到达接收方）

在采用快恢复算法时，慢开始算法只是在TCP连接建立时和网络出现超时时才使用。

发送窗口取决于接受窗口和拥塞窗口二者的最小值

TCP连接建立

TCP连接释放

HTTP

HTTP使用了面向连接的TCP作为运输层协议，保证了数据的可靠传输

请求一个URL的过程：

1、浏览器分析URL

2、浏览器请求解析域名（寻找 IP 地址的过程依次经过了浏览器缓存、系统缓存、hosts 文件、路由器缓存、 递归搜索根域名服务器）

3、DNS解析得到IP地址

4、浏览器根据IP地址创建TCP连接

5、浏览器发出命令 如GET请求等

6、服务器解析http请求，返回html

7、浏览器解析html并展示

8、释放TCP连接

Http 1.0和1.1的区别

HTTP1.0缺点：

非持续连接：每请求一次就要创建一次TCP连接，就要花费2*RTT的时间，而且客户端和服务器每次都要为创建TCP连接分配缓存和变量

HTTP 1.1：

持续连接：服务器发送响应后仍在一段时间内保持这个连接

如何实现长连接？

在http头部加上：Connection:keep-alive

Http报文结构

HTTP的报文结构：

1、开始行

2、首部行

3、实体主体

请求报文的方法

Http的状态码（响应报文的状态行里面）

1XX：接受的请求正在处理

2XX：请求正常处理完毕

3XX：需要进行附加操作以完成请求

4XX：服务器无法处理请求

5XX：服务器处理请求错误

https和http的区别

Http连接建立过程

Http请求报文，会作为建立TCP连接的三报文握手中第三个报文的数据，发送给万维网服务器。