计算机网络总结

一、体系结构

image.png

  • 应用层:应用层协议定义的是应用进程间通信和交互的规则, 为特定应用程序提供数据传输服务,例如 HTTP、DNS 等。数据单位为报文
  • 运输层:运输层的任务就是负责向两台主机中进程之间的通信提供通用的数据传输服务(TCP或UDP)
  • 网络层:把运输层产生的报文段或用户数据报封装成分组或包进行传送
  • 数据链路层:将网络层交下来的 IP 数据报组装成帧,并在两个相邻结点间的链路上传送
  • 物理层:利用物理媒体以比特形式传送数据

物理层信道复用技术

基本概念

信道,向某一个方向传送信息的媒体,包括

  • 单向信道:一方发送,一方接收,单工
  • 双向交替信道:双方都可发送消息,但不能同时进行,半双工
  • 双向同时信道:双方可同时发送信息,全双工

复用,即信道共享,几种常见的信道复用技术:频分复用,时分复用,统计时分复用。通过复用器和分用器进行信号的复用和分用

信道复用技术

1. 频分复用FDM
用户在同样的时间内占用不同的频率带宽而复用同一个信道

2. 时分复用TDM
将时间划分为相同的时分复用帧TDM,在不同的时间占用相同的频带宽度,

*3. 统计时分复用STDM *
改进的时分复用,按需动态分配时隙,而不是固定分配时隙 (时隙数小于连接在集中器上的用户数,使得每次传送的STDM帧中的分组都是满的

4. 波分复用WDM
光的频分复用,利用在光线技术通信中;

5. 码分复用CDM
每个用户在相同的时间使用相同的频带进行通信,但各用户使用经过挑选的不同码型,从而使得个用户之间可以进行独立的通信

数据链路层

数据链路层的主要功能:

  • 链路管理
  • 帧同步
  • 流量控制
  • 差错控制
  • 将数据与控制信息区分开
  • 透明传输
  • 寻址

数据链路层的三个基本问题:封装成帧透明传输差错检测

封装成帧

将IP数据报的前后分别添加首部和尾部构成帧,以便于接收端能够在物理层的比特流中知道帧的开始和结束,即进行帧定界

此外,首部和尾部还要添加许多控制信息,链路层协议规定了所能传送的帧的数据部分长度上限,最大传送单元——MTU
image.png

透明传输

透明传输的概念是指在数据链路层传输时,所传输的数据在数据链路层没有任何的阻挡,接收方所收到的数据和发送方发送的数据没有任何差别,也就是说,数据链路层对其传输的数据帧是完全透明的;

字节填充:
在传输的过程中,为防止数据部分出现帧定界符,使得接收方误以为收到的数据提前结束,所以采用转义字符的方法,将在数据部分出现的控制字符前插入转义字符,,在接收方的数据链路层将插入的转义字符删除
image.png

零比特填充法:
只要发现5个连续1,则立即填入一个0,保证不出现6个连续1

差错检测

差错检测指的是在传输过程中产生的比特差错;

误码率:一段时间内,传输错误的比特占传输总数的比率;

目前在数据链路层采用的差错检验方式是循环冗余检验

注:
在数据链路层我们保证的是无比特差错,而并无传输差错,传输差错还包含帧丢失帧重复帧失序等;

二、IP地址

概述

计算机要实现网络通信,就必须要有一个用于快速定位的网络地址。IP地址就是计算机在网络中的唯一身份ID,与现实世界中快递的配送需要有具体的住宅地址是一个道理。

IP地址 = 网络地址 + 主机地址(又称:主机号和网络号组成)

网段划分

A类地址:以0开头,第一个字节范围:0 - 127(1.0.0.0 - 126.255.255.255);
B类地址:以10开头, 第一个字节范围:128 - 191(128.0.0.0 - 191.255.255.255);
C类地址:以110开头, 第一个字节范围:192 - 223(192.0.0.0 - 223.255.255.255);
Internet上保留地址用于内部私有使用: 10.0.0.0 - 10.255.255.255172.16.0.0 - 172.31.255.255192.168.0.0 - 192.168.255.255

image.png

子网掩码

  • 在划分子网的时候,我们将本来属于主机号的一部分划分到网络号中,为了便于区分哪部分是网络号,哪部分是主机号,这就需要通过子网掩码来实现

  • 子网掩码不能单独存在,它必须结合IP地址一起使用。

  • 子网掩码只有一个作用,就是将某个IP地址划分成网络地址和主机地址两部分。

子网掩码的计算

利用子网数来计算子网掩码

计算规则:

  1. 将子网数目转化为二进制来表示

  2. 取得该二进制的位数,为 N

  3. 取得该IP地址的类子网掩码,将其主机地址部分的前N位置1 即得出该IP地址划分子网的子网掩码

如欲将B类IP地址168.195.0.0划分成27个子网:

1)27=11011

2)该二进制为五位数,N = 5

3)将B类地址的子网掩码255.255.0.0的主机地址前5位置 1,得到 255.255.248.0即为划分成 27个子网的B类IP地址 168.195.0.0的子网掩码

利用主机数来计算子网掩码

计算规则:

  1. 将主机数目转化为二进制来表示

  2. 如果主机数小于或等于254(注意去掉保留的两个IP地址),则取得该主机的二进制位数,为 N,这里肯定N<8。如果大于254,则 N>8,这就是说主机地址将占据不止8位。

  3. 使用255.255.255.255来将该类IP地址的主机地址位数全部置1,然后从后向前的将N位全部置为 0,即为子网掩码值

如欲将B类IP地址168.195.0.0划分成若干子网,每个子网内有主机700台:

1) 700=1010111100

2)该二进制为十位数,N = 10

3)将该B类地址的子网掩码255.255.0.0的主机地址全部置 1,得到255.255.255.255 然后再从后向前将后 10位置0,即为: 11111111.11111111.11111100.00000000 即255.255.252.0。这就是该欲划分成主机为700台的B类IP地址 168.195.0.0的子网掩码

三、UDP

概述

  • 用户数据报协议UDP只在IP的数据报服务至上增加了复用和分用的功能以及差错检测的功能。只有面向无连接的报文不可靠传输的特点。
  • UDP对应用层交下来的数据只添加首部,并进行特别的处理,就交给网络层;
  • 对网络层传递上来的用户数据报拆封首部后,原封不动的交给应用层
    image.png

UDP首部格式

image.png

UDP首部字段很简单,由4个字段组成,每个字段的长度都是两个字节,共8字节。

  • 源端口号:在需要对方回信时选用,不需要时可全0
  • 目的端口号:这在终点交付报文时必须使用,不然数据交给谁呢?
  • 长度: UDP的长度,最小值为8字节,仅有首部
  • 检验和: 检测用户数据报在传输过程是否有错,有错就丢弃。

在传输的过程中,如果接收方UDP发现收到的报文中的目的端口不存在,会直接丢弃,然后由网际控制报文协议ICMP给发送方发送“端口不可达”差错报文

关于循环冗余校验法,详见: CRC(循环冗余校验码)简介与实现解析

四、TCP

TCP协议作为传输层主要协议之一,是面向连接,端到端,可靠的全双工通信,面向字节流的数据传输协议

TCP报文段

虽然TCP面向字节流,但TCP传输的数据单元却是报文段。TCP报文段分为TCP首部数据部分,TCP报文段首部的前20个字节是固定的,后面有4n 字节根据需要动态添加的选项,最大长度为40字节
image.png

  • 源端口和目的端口 各占两个字节,TCP的分用功能也是通过端口实现的。

  • 序号(Sequence Number) 占4个字节,范围是[0,232],TCP是面向字节流的,每个字节都是按顺序编号。例如一个报文段,序号字段是201,携带数据长度是100,那么第一个数据的序号就是201,最后一个就是300。当达到最大范围,又从0开始。

  • 确认号 占4个字节,是期望收到对方下一个报文段的第一个字节的序号。若确认号=N,则表示序号N前所有的数据已经正确收到了。

  • 数据偏移 占4位,表示报文段的数据部分的起始位置,距离整个报文段的起始位置的距离。间接的指出首部的长度。

  • 保留 占6位,保留使用,目前为0.

  • URG(紧急) 当URG=1,表明紧急指针字段有效,该报文段有紧急数据,应尽快发送。

  • 确认号(Acknowledgement Number) 仅当ACK=1时,确认号才有效,连接建立后,所有的报文段ACK都为1。

  • PSH(推送) 接收方接收到PSH=1的报文段,会尽快交付接收应用经常,不再等待整个缓存填满再交付。实际较少使用。

  • RST(复位) RST=1时,表明TCP连接中出现严重差错,必须是否连接,再重连。

  • SYN(同步) 在建立连接时用来同步序号。当SYN=1,ACK=0,则表明是一个连接请求报文段。SYN=1,ACK=1则表示对方同意连接。TCP建立连接用到。

  • FIN(终止) 用来释放一个连接窗口。当FIN=1时,表明此报文段的发送方不再发送数据,请求释放单向连接。TCP断开连接用到。

  • 窗口 占2个字节,表示发送方自己的接收窗口,窗口值用来告诉对方允许发送的数据量。

  • 校验和 占2字节,检验和字段查验范围包括首部和数据部分。

  • 紧急指针 占2字节,URG=1时,紧急指针指出本报文段中的紧急数据的字节数(紧急字节数结束后为普通字节)。

  • 选项 长度可变,最长可达40字节。例如最大报文段长度MSS。MSS指的是数据部分的长度而不是整个TCP报文段长度,MSS默认为536字节长。窗口扩大,时间戳选项等

三次握手

image.png

  • 第一次:客户端发送连接请求报文给服务端,其中SYN=1,seq=x(代表客户端的初始序列号),即ISN(Initial Sequence Number, 初始序号)。发送完毕后进入SYN_END状态。

  • 第二次:服务端接收到报文后,发回确认报文,其中ACK=1,ack=x+1,因为需要客户端确认,所以报文中也有SYN=1,seq=y的信息。发送完后进入SYN_RCVD状态。

  • 第三次:客户端接收到报文后,发送确认报文,其中ACK=1,ack=y+1。发送完客户端进入ESTABLISHED状态,服务端接收到报文后,进入ESTABLISHED状态。到此,连接建立完成

三次握手原因
避免资源被浪费掉。如果在第二步握手时,由于网络延迟导致确认包不能及时到达客户端,那么客户端会认为第一次握手失败,再次发送连接请求,服务端收到后再次发送确认包。在这种情况下,服务端已经创建了两次连接,等待两个客户端发送数据,而实际却只有一个客户端发送数据, 就会造成资源浪费

四次挥手

四次挥手指客户端和服务端各发送一次请求终止连接的报文,同时双方响应彼此的请求
image.png

  • 第一次挥手:客户端发送FIN=1,seq=x的包给服务端,表示自己没有数据要进行传输,单面连接传输要关闭。发送完后,客户端进入FIN_WAIT_1状态。

  • 第二次挥手:服务端收到请求包后,发回ACK=1,ack=x+1的确认包,表示确认断开连接。服务端进入CLOSE_WAIT状态。客户端收到该包后,进入FIN_WAIT_2状态。此时客户端到服务端的数据连接已断开。

  • 第三次挥手:服务端发送FIN=1,seq=y的包给客户端,表示自己没有数据要给客户端了。发送完后进入LAST_ACK状态,等待客户端的确认包。

  • 第四次挥手:客户端收到请求包后,发送ACK=1,ack=y+1的确认包给服务端,并进入TIME_WAIT状态,有可能要重传确认包。服务端收到确认包后,进入CLOSED状态,服务端到客户端的连接已断开。客户端等到一段时间后也会进入CLOSED状态。

注:

  • 默认情况下(不改变socket选项),当你调用close( or closesocket,以下说close不再重复)时,如果发送缓冲中还有数据,TCP会继续把数据发送完。
  • 发送了FIN只是表示这端不能继续发送数据(应用层不能再调用send发送),但是还可以接收数据

四次挥手原因
由于TCP的连接是全双工,双方都可以主动传输数据,一方的断开需要告知对方,让对方可以进行后续相关操作,负责任的表现。

基于TCP传输的协议有:FTP(文件传输协议)Telnet(远程登录协议)SMTP(简单邮件传输协议)POP3(和SMTP相对,用于接收邮件)HTTP协议

“三次握手,四次挥手”补充

ISN

三次握手的一个重要功能是客户端和服务端交换ISN, 以便让对方知道接下来接收数据的时候如何按序列号组装数据。
如果ISN是固定的,攻击者很容易猜出后续的确认号
ISN = M + F(localhost, localport, remotehost, remoteport)
M是一个计时器,每隔4毫秒加1。 F是一个Hash算法,根据源IP、目的IP、源端口、目的端口生成一个随机数值。要保证hash算法不能被外部轻易推算得出

TIME_WAIT状态详解

TIME_WAIT状态设置为2 * Maximum Segment Lifetime(报文最大生存时间), 存在TIME_WAIT状态的原因:

  • LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文而重发FIN报文,所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文

  • 确保连接断开,假如要关闭的这个链接后面在相同的IP地址和端口去建立一个新连接,可能会被误认为是旧连接的新请求(一个tcp Session由【源IP、源端口、目的IP、目的端口】四元组唯一决定),由于TCP报文段最大生存时间为MSL,其保持2MSL时间可以确保网络上两个传输方向的尚未接收到的、迟到的报文段都已经消失,或被路由器丢弃,而2MSL时间后建立新的连接其绝不会收到原来连接的应用程序数据。这样通过设置一个2MSL时长的TIME_WAIT状态可以让新的连接其绝不会收到原来连接的应用程序数据

序列号回绕

因为ISN是随机的,所以序列号容易就会超过2^31-1. 而tcp对于丢包和乱序等问题的判断都是依赖于序列号大小比较的,此时就出现了所谓的tcp序列号回绕(sequence wraparound)问题

半连接和全连接

半连接队列:
服务器第一次收到客户端的 SYN 之后,就会处于 SYN_RCVD 状态,此时双方还没有完全建立其连接,服务器会把此种状态下请求连接放在一个队列里,我们把这种队列称之为半连接队列

全连接队列:
已经完成三次握手,建立起连接的就会放在全连接队列中,如果队列满了就有可能会出现丢包现象

其他例如syn flood攻击Syn Cache技术Syn Cookie技术SYN Proxy防火墙等详细请参考:“三次握手,四次挥手”你真的懂吗?

TCP可靠传输

可靠的传输应该满足:

  • 传输的信道不产生差错;

  • 保证传输数据的正确性,无差错、不丢失、不重复、并且按序到达

TCP可靠传输的实现:

  • 采用三次握手来建立TCP连接,四次握手来释放TCP连接,从而保证建立的传输信道是可靠的。

  • TCP采用了ARQ协议来保证数据传输的正确性

  • TCP使用滑动窗口协议来保证接方能够及时处理所接收到的数据,进行流量控制。

  • TCP使用慢开始拥塞避免快重传快恢复来进行拥塞控制,避免网络拥塞

滑动窗口协议

滑动窗户协议是指数据发送方有一个发送窗口,发送窗口范围内的数据允许发送,随着接收方传来的确认信息以及通知的接收窗口的大小来动态调整发送窗口的起始位置以及大小
窗口的滑动有三种情况:

  • 前沿向右移动,这种情况发生在数据发送并被确认时。
  • 后沿向右移动,允许发送更多数据。这种情况发生在接收窗口增大或者网络拥塞情况缓解时。
  • 后沿向左移动,这种情况发生在接收方希望发送窗口缩小时,TCP标准强烈不建议出现这种情况。因为发送方在收到缩小窗口的通知时,可能已经发送了一些缩小部分的数据,容易造成错误
  • 窗口前沿无法向左移动,因为TCP会将窗口之外已经收到确认的数据清除出缓存

ARQ协议

ARQ 自动重传请求(Automatic Repeat-reQuest)是一种在数据传输时,使用确认(Acknoledgements,就是我们常说的ACK,接收方发送一个消息,告诉发送方,自己是否正确接到了一个包体)和超时(Timeouts,在收到一个确认消息之前,等待的一个确定的时间段)机制,在不可靠的网络上,实现可靠的数据传输的错误控制方法策略,包括停止等待ARQ协议连续ARQ协议错误侦测(Error Detection)正面确认(Positive Acknowledgment)逾时重传(Retransmission after Timeout)与负面确认继以重传(Negative Acknowledgment and Retransmission)等机制

停止等待ARQ:
“停止等待”是指每发送完一个分组就停止发送,等待对方确认,在收到对方确认后再发送下一个分组,有两种错误情况

  • 当接收方收到错误数据分组时,会直接丢弃分组。
  • 发送方在一定时间没有收到确认,则会重传分组,即超时重传

连续ARQ协议:

  • 滑动窗口协议 与 自动重传请求技术结合形成连续ARQ协议。连续ARQ协议根据超时重发数据方式的不同分为后退N帧ARQ协议选择重发ARQ协议

  • 发送方每收到一个确认,就把发送窗口向前滑动一个分组的位置。

  • 接收方一般都是采用累积确认(ACK机制)的方式。这就是说接收方不必对收到的分组逐个发送确认,而是可以在收到几个分组后对按序到达的最后一个分组发送确认,这样就表示:到这个分组为止的所有分组都已正确收到了

后退N帧 ARQ(Go-Back-N ARQ)

GBN是在发送完一个数据帧后,不停下来等待确认帧,而是可以连续再发若干帧,边发可以边等待确认帧,如果收到了确认帧,又可以继续发送数据帧, 由于减少了等待的时间,利用率就提高了。但是如果接收到错误帧的话,所有该帧后面的帧都要重发

选择性重发/拒绝 ARQ (Selective Repeat/Reject ARQ)

相对于后退N帧 ARQ,在收到错误帧的情况下不需要再重传所有的,只需要选择错误的帧进行重发,进一步提高了复用率。但同时牺牲了空间,因为它需要将已经接收到的正确的信息缓存下来,直到所有信息正确被接收到然后再发送确认收到

流量控制

 通过TCP连接发送数据,如果发送方发送数据很慢,容易造成资源浪费;如果发送方发送数据过快,接收方来不及接收会造成数据丢失。流量控制就是指在接收方能够接收的范围内,合理而又快速的发送数据。  

基于滑动窗口的流量控制

在TCP连接建立时,接收方会在确认报文段中给出自己接收窗口的大小。在每次发送确认报文时能够根据情况动态调整接收窗口的大小,并将告知发送方。如下图所示:
image.png

发送方发送序号从1开始的100字节的数据,接收方在确认报文中声明自身的接收窗口大小为300字节。之后发送方发送300字节数据,接收方在确认报文中声明自身接收窗口大小调整为50字节。发送方再发送50字节数据之后,收到接收方传来的确认报文,在该报文中声明接收窗口为0。

 在接收方接收窗口为0时,发送方不再发送数据,直到接收方发送确认报文表明窗口大小发生改变。可是这个确认报文不一定能够被发送方接收到,如果一旦该确认报文丢失,双方都将处于等待中,形成死锁。为防止这种情况出现,TCP规定在收到对方接受窗口为0时,启动一个坚持定时器周期性的发送探测报文,以确定对方接收窗口为0的状态是否改变

 另外,TCP标准规定:接收方接收窗口为0时,不再接收正常数据,但是可以接收零窗口探测报文段、确认报文段、携带紧急数据的报文段

拥塞控制

TCP进行拥塞控制常用的算法有四种:慢启动拥塞避免快重传快恢复

慢启动

TCP为发送方维持一个拥塞窗口,记为cwnd, 拥塞窗口的值跟SMSS有关,SMSS为发送的最大报文段长度
慢启动算法规定:拥塞窗口初始化后,每收到一个对新报文的确认,拥塞窗口就加一个SMSS的大小。拥塞窗口以字节为单位,但是慢启动以SMSS大小为单位增加。按照慢启动算法,经过一轮传输,拥塞窗口就增大一倍,这是一种指数增长的关系

拥塞避免

慢启动算法除了维持拥塞窗口cwnd变量之外,还维持另一个变量慢启动门限ssthresh。当cwnd以指数增长的形式增长到大于或等于ssthresh时,就不再采用慢启动算法,而是采用拥塞避免算法来进行拥塞控制。
拥塞避免算法规定:每次收到一个确认时将cwnd增加1/cwnd个SMSS。即不再是像慢启动算法那样经过一轮传输cwnd翻倍了,而是经过一轮传输增加一个SMSS。这是一种加性增长的关系,当拥塞发生时(超时或收到重复确认),cwnd被设置为1个SMSS。ssthresh被设置为当前窗口大小的一半,但最少为 2个报文段

总结就是:加性增,乘性减

快重传

 如果个别报文段在网络中丢失,网络并没有发生拥塞,这种情况下发送方收不到确认报文,在超时之后会重传该报文。发送方误以为网络发生拥塞,错误的启动慢开始算法,降低了传输效率。
  采用快重传算法可以让发送方尽早知道个别报文段的丢失。快重传算法要求接收方不要延时发送确认,即使收到失序的报文段也要立刻发送对已收到报文的重复确认。如下图所示:
image.png
接收方收到M1之后发送对M1的确认报文,M2报文丢失,之后接收方收到M3、M4、M5时每次都发送对M1报文的重复确认。快重传算法规定当收到三次重复确认后,发送方就认为M2报文段丢失,立即重传M2报文段,而不用等待超时时再重传,这样可以避免发送方误认为网络发生拥塞

快恢复

在快重传算法执行后,发送方知道只是丢失个别报文,而不是网络发生拥塞。之后并不会执行慢启动算法,而是执行快恢复算法:调整门限值ssthresh = cwnd/2,同时设置cwnd = ssthresh + 3 SMSS。设置拥塞窗口的值为门限值加3个报文段是因为发送方收到三个确认报文,就认为有三个分组已经离开网络到达接收方的缓存,这三个确认报文不再占用网络资源,可以适当增大拥塞窗口的大小

拥塞控制和流量控制的区别
  • 拥塞控制:拥塞控制是作用于网络的,它是防止过多的数据注入到网络中,避免出现网络负载过大的情况

  • 流量控制:流量控制是作用于接收者的,它是控制发送者的发送速度从而使接收者来得及接收,防止分组丢失的

五、TCP和UDP的区别

  • TCP 面向字节流,UDP 面向报文;
  • TCP 面向连接(需要三次握手),UDP 面向非连接;
  • TCP 提供可靠的数据传输服务,有丢包重传机制且保证数据顺序,UDP 可能会丢包也不保证数据顺序
  • 每一条TCP连接只能是点到点的;UDP支持一对一,一对多,多对一和多对多的交互通信
  • TCP要求系统资源较多,UDP较少

具体编程时的区别,socket()的参数不同

  • UDP Server不需要调用listen和accept
  • UDP收发数据用sendto/recvfrom函数
  • TCP:地址信息在connect/accept时确定
  • UDP:在sendto/recvfrom函数中每次均 需指定地址信息
  • UDP:shutdown函数无效

六、HTTP协议

HTTP协议是超文本传输协议的缩写,英文是Hyper Text Transfer Protocol。它是从WEB服务器传输超文本标记语言(HTML)到本地浏览器的传送协议, 基于TCP/IP通信协议来传递数据

报文格式

image.png

常见请求头

  • Accept:用于高速服务器,客户机支持的数据类型
  • Accept-Charset:用于告诉服务器,客户机采用的编码格式
  • Accept-Encoding:用于告诉服务器,客户机支持的数据压缩格式
  • Accept-Language:客户机的语言环境
  • Host:客户机通过这个头高速服务器,想访问的主机名
  • If-Modified-Since:客户机通过这个头告诉服务器,资源的缓存时间
  • Referer:客户机通过这个头告诉服务器,它是从哪个资源来访问服务器的(防盗链)
  • User-Agent:客户机通过这个头告诉服务器,客户机的软件环境
  • Cookie:客户机通过这个头可以向服务器带数据
  • Connection:处理完这次请求后是否断开连接还是继续保持连接
  • Date:当前时间值

常见响应头

  • Location: 表示重定向的地址,该头和302的状态码一起使用。
  • Server: 表示服务器的类型
  • Content-Encoding: 表示服务器发送给浏览器的数据压缩类型
  • Content-Length: 表示服务器发送给浏览器的数据长度
  • Content-Language: 表示服务器支持的语言
  • Content-Type: 表示服务器发送给浏览器的数据类型及内容编码
  • Last-Modified: 表示服务器资源的最后修改时间
  • Refresh: 表示定时刷新
  • Content-Disposition: 表示告诉浏览器以下载方式打开资源(下载文件时用到)
  • Transfer-Encoding: 告诉浏览器数据的传送格式
  • Set-Cookie: 表示服务器发送给浏览器的cookie信息(会话管理用到)
  • Expires: 告诉浏览器把回送的资源缓存多长时间 -1或0则是不缓存
  • Cache-Control: no-cache
  • Pragma: no-cache
    服务器通过以上两个头,也就是控制浏览器不要缓存数据
  • Connection: 表示服务器和浏览器的连接状态。close:关闭连接 keep-alive:保存连接

请求状态码

状态码分类

  • 1XX- 信息型,服务器收到请求,需要请求者继续操作。
  • 2XX- 成功型,请求成功收到,理解并处理。
  • 3XX - 重定向,需要进一步的操作以完成请求。
  • 4XX - 客户端错误,请求包含语法错误或无法完成请求。
  • 5XX - 服务器错误,服务器在处理请求的过程中发生了错误

常见请求状态码

  • 200 OK 请求已成功
  • 204 No Content 无内容,服务器成功处理了请求没有返回任何内容
  • 301 Moved Permanently 被请求的资源已移动,永久重定向
  • 302 Found 已找到,临时重定向
  • 304 Not Modified 未修改,客户的缓存资源是最新的,要客户端使用缓存
  • 400 Bad Request 客户端请求有语法错误,不能被服务器所理解
  • 401 Unauthorized 未授权,未授权客户机访问数据
  • 403 Forbidden 禁止,没有权限访问
  • 404 Not Found 请求资源不存在,可能是输入了错误的URL
  • 405 Method Not Allowed 方法不允许
  • 406 Not Acceptable 请求的资源的内容特性无法满足请求头中的条件,因而无法生成响应实体
  • 500 Internal Server Error 内部服务器错误
  • 502 Bad Gateway 无效网关,作为网关或者代理的服务器执行请求时接收到无效的响应
  • 503 Service Unavailable 服务不可用,服务器由于维护或者负载过重未能应答
  • 504 Gateway Timeout 网关连接超时,网关或者代理的服务器无法在规定的时间内应答

Post和Get请求的异同

  • GET请求的数据会附在URL之后(就是把数据放置在HTTP协议头中),以?分割URL和传输数据,参数之间以&相连。POST把提交的数据则放置在是HTTP包的包体中

  • Get可提交的数据量较小(因为数据附在URL之后)、而Post提交的数据量较大,浏览器和服务器会有不同的限制

  • Post安全性比Get高,GET的数据在 URL 中对所有人都是可见的;说Get是安全的指的仅仅是非修改信息,Get用于获取/查询资源信息,Post用于更新资源信息

  • GET是幂等的,POST不是

  • GET编码类型application/x-www-form-url,POST编码类型encodedapplication/x-www-form-urlencoded 或 multipart/form-data

  • GET历史参数保留在浏览器历史中。POST参数不会保存在浏览器历史中

幂等性

HTTP方法的幂等性是指一次和多次请求某一个资源应该具有同样的副作用。即:同一个请求,发送一次和发送N次效果是一样的!
幂等的方法:GET、DELETE、PUT
PUT与POST均是创建或更新,唯一不同是POST非幂等

http1.x/2.0

http1.1

  • 引入了持久连接( persistent connection),即TCP连接默认不关闭,可以被多个请求复用,不用声明Connection: keep-alive。

  • 引入了管道机制( pipelining),即在同一个TCP连接里,客户端可以同时发送多个

  • 请求,进一步改进了HTTP协议的效率。

  • 新增方法:PUT、 PATCH、 OPTIONS、 DELETE。

  • http协议不带有状态,每次请求都必须附上所有信息。请求的很多字段都是重复的,浪费带宽,影响速度

http2.0

  • http/2是一个彻底的二进制协议,头信息和数据体都是二进制,并且统称为”帧”(frame):头信息帧和数据帧。 避免 http1.x在传输数据时明文传输内容容易导致的安全性问题

  • 复用TCP连接,在一个连接里,客户端和浏览器都可以同时发送多个请求或回应,且不用按顺序一一对应,避免了队头堵塞的问题,此双向的实时通信称为多工( Multiplexing)。

  • HTTP/2 允许服务器未经请求,主动向客户端发送资源,即服务器推送

  • 引入头信息压缩机制( header compression) ,头信息使用gzip或compress压缩后再发送

https

HTTPS 经由 HTTP 进行通信,利用 SSL/TLS 协议来加密数据包,是 HTTP 的安全版,与http主要区别:

  • HTTPS 协议需要到CA申请证书
  • HTTP 和 HTTPS 使用端口不一样,前者是80,后者是443
  • HTTP 协议运行在 TCP 之上,所有传输的内容都是明文,HTTPS 运行在 SSL/TLS 之上,SSL/TLS运行在TCP之上,所有传输的内容都经过加密的
  • HTTPS 可以有效的防止运营商劫持

七、浏览器输入域名到展示页面过程

事件顺序:

  1. DNS 域名解析:浏览器缓存–> 操作系统缓存–> 本地host文件 –> 路由器缓存–> ISP DNS缓存 –> 顶级DNS服务器/根DNS服务器,查找域名对应的 IP 地址
  2. 建立 TCP 连接: TCP 采用三次握手与服务器建立连接,提供可靠的传输服务
  3. 发送 HTTP 请求:通过 TCP 连接把 HTTP 报文发送给服务器
  4. 服务器处理请求并返回 HTTP 报文
  5. 浏览器渲染页面:首先浏览器解析 HTML 文件构建 DOM 树,然后解析 CSS 文件构建渲染树,等到渲染树构建完成后,浏览器开始布局渲染树并将其绘制到屏幕

涉及到的协议:

  • 应用层:HTTP(WWW访问协议),DNS(域名解析服务)
    DNS 维护着 域名(domain name)和IP地址 (IP address)的对照表表,以解析消息的域名。

  • 传输层:TCP(为HTTP提供可靠的数据传输),UDP(DNS使用UDP传输)

  • 网络层:IP(IP数据数据包传输和路由选择),ICMP(提供网络传输过程中的差错检测),ARP(将本机的默认网关IP地址映射成物理MAC地址)

八、session和cookie区别

  • cookie数据存放在客户的浏览器上,session数据放在服务器上。

  • cookie不是很安全,别人可以分析存放在本地的COOKIE并进行COOKIE欺骗

  • 考虑到安全应当使用session。

  • session会在一定时间内保存在服务器上。当访问增多,会比较占用你服务器的性能。考虑到减轻服务器性能方面,应当使用COOKIE。

  • 单个cookie保存的数据不能超过4K,很多浏览器都限制一个站点最多保存20个cookie

补充

session在一定程度上依赖于cookie。服务端执行session机制时候会生成session的id值,这个id值会发送给客户端,客户端每次请求都会把这个id值放到http请求的头部发送给服务端,而这个id值在客户端会保存下来,保存的容器就是cookie

九、长连接和短连接与WebSocket

长连接和短连接

长连接和短连接区别

在HTTP/1.0中,默认使用的是短连接。也就是说,浏览器和服务器每进行一次HTTP操作,就建立一次连接,但任务结束就中断连接
从 HTTP/1.1起,默认使用长连接,用以保持连接特性。使用长连接的HTTP协议,会在响应头设置:Connection:keep-alive
在使用长连接的情况下,当一个网页打开完成后,客户端和服务器之间用于传输HTTP数据的 TCP连接不会关闭,如果客户端再次访问这个服务器上的网页,会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接,它有一个保持时间,可以在不同的服务器软件(如Apache)中设定这个时间。实现长连接要客户端和服务端都支持长连接。

HTTP协议的长连接和短连接,本质上是TCP协议的长连接和短连接

长连接和短连接应用场景

  • 长连接多用于操作频繁,点对点的通讯,而且连接数不能太多情况。每个TCP连接都需要三步握手,这需要时间,如果每个操作都是先连接,再操作的话那么处理速度会降低很多,所以每个操作完后都不断开,次处理时直接发送数据包就OK了,不用建立TCP连接。 例如:数据库的连接用长连接, 如果用短连接频繁的通信会造成socket错误,而且频繁的socket 创建也是对资源的浪费。

  • 而像WEB网站的http服务一般都用短链接,因为长连接对于服务端来说会耗费一定的资源,而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源,如果用长连接,而且同时有成千上万的用户,如果每个用户都占用一个连接的话,那可想而知吧。 所以并发量大,但每个用户无需频繁操作情况下需用短连接好

短轮训和长轮训

和短连接和长连接有本质区别。长、短连接是客户端与服务端建立和保持TCP连接的机制;而长、短轮询是指客户端请求服务端,服务端给予应答的方式。

  • 短轮询:重复发送Http请求,查询目标事件是否完成,优点:编写简单,缺点:浪费带宽和服务器资源

  • 长轮询:在服务端hold住Http请求(死循环或者sleep等等方式),等到目标时间发生(保持这个请求等待数据到来或者恰当的超时),返回Http响应。优点:在无消息的情况下不会频繁的请求,缺点:编写复杂

WebSocket

WebSocket连接建立

客户端浏览器首先要向服务器发起一个HTTP请求,这个请求和通常的HTTP请求不同,包含了一些附加头信息,其中附加头信息“Upgrade: WebSocket”表明这是一个申请协议升级的HTTP请求

WebSocket和HTTP长连接区别

  • HTTP1.1通过使用Connection:keep-alive进行长连接,HTTP 1.1默认进行持久连接。在一次 TCP 连接中可以完成多个 HTTP 请求,但是对每个请求仍然要单独发 header,Keep-Alive不会永久保持连接,它有一个保持时间,可以在不同的服务器软件(如Apache)中设定这个时间。
  • websocket的长连接,是一个真的全双工,第一次tcp链路建立之后,后续数据可以双方都进行发送,不需要发送请求头,并且这个连接会持续存在直到客户端或者服务器端的某一方主动关闭连接,与HTTP长连接不同,WebSocket可以更灵活的控制连接关闭的时机,而不是HTTP协议的Keep-Alive一到,服务端立马就关闭(这样很不人性化)

十、参考链接