网络通信协议基础

1.网络分层

 

Frame -> 物理层

提供网络通信环境：光纤，电缆等物理设备

Ethernet -> 数据链路层

提供线路之前的无差错链接，包括差错控制，流量控制

Internet -> 网络层

寻址，路由，分段组合，拥塞控制

Transmission Control Protocol -> 传输层

应用层交互，提供透明数据交互

OSI：应用层，表示层，会话层，传输层，网络层，数据链路层，物理层

2.TCP/UDP介绍

TCP:双工互通,提供可靠网络传输协议，具备数据分包，解包，组装功能，点对点。HTTP、FTP、Telnet、DNS、SMTP

UDP:用户数据协议，支持一对一，一对多广播。传输效率更高，但不安全。（QQ等及时通讯产品，视频通信）

3.TCP握手机制

 

srcPort:源端口

dstPort:目的端口

SeqNumber:请求序号

AckNumber:响应序号

Header Length:头长度，校验和:二进制和的反码

 

window:窗口

Flags:标识字段

ACK:响应链接

FIN:关闭链接

PUSH:数据传输

RST:重置操作

RVT:预留字段

SYN:建立链接

 

三次握手：

 

第一次握手：src->dst:seq=0

第二次握手：dst->src:seq=0,ack=1

第三次握手：src->dst:seq=1,ack=1

 

SYN攻击：SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server回复确认包，并等待Client的确认，由于源地址是不存在的，因此，Server需要不断重发直至超时。这些伪造的SYN包将产时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络堵塞甚至系统瘫痪。

 

四次握手:

关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手

 

4.TCP超时重传机制：

网络能够提供的资源不足以满足用户的需求，这些资源包括缓存空间、链路带宽容量和中间节点的处理能力

 

流量控制：

设置滑动窗口（window），充分利用网络资源。确定发送数据大小，避免网络过载。弊端：只是考虑客户端和服务器端数据传输大小，利用缓存的方式解决数据包过大的问题，但是没有考虑网络的承载能力。

 

拥塞机制：

慢启动：TCP初始化一个拥塞窗口cwnd大小，收到ACK后增加数据包大小

拥塞避免：增加一个阀值，超时后将阀值/2,减少数据包大小

快速重传：缓存segment数据，ackNum的连续的，出现重复的ack则判定数据丢失，启动重传功功能。

 

案例：弱网机制下重复请求，后台接口的幂等处理

 

5.IP网段划分

IPV4:2^4 32位 256

IPV6:2^6 64位

NetId->用来区分网段 HostId->服务器IP

A:(0-127),子掩码：255.0.0.0 2^24

B:(128-191),子掩码：255.255.0.0 2^16

C:(192-223)，子掩码：255.255.255.0 2^8

 

判断IP在同一网段计算：

IP->二进制，子掩码->二进制，进行AND操作 0&0 =0 0&1=0 1&1=1

 

DNS:

根域名“”/顶级域名com.cn/本地域名baidu.com

域名解析过程：

请求->

->本地缓存-> 本地域名

->没有缓存-> 根服务器（13）->顶级服务器(cn,com,org)->本地域名

6.HTTP协议

请求头：Accept、Accept-language、Connection、content-type、host

 

状态码：200,300,404,401,505

Cookier:内存、磁盘。客户端存储的

 

http是无状态化的，那么页面的逻辑如何保证？

Domain:

Path:

Expire time/Max-age:

Httponly:

cookie会被附加在每个HTTP请求中，所以无形中增加了流量。

由于在HTTP请求中的cookie是明文传递的，所以安全性成问题。（除非用HTTPS)

Cookie的大小限制在4KB左右。对于复杂的存储需求来说是不够用的。

sessions:OAUTH2.0

服务器端保存的状态信息，跟踪用户