TCP/UDP传输的数据
UDP对应用层传输的数据不做合并拆分，只是简单的加上首部后传输给网络层（不管报文有多长）
TCP对应用层传输的数据看成 无结构化的，将数据放在缓冲区，允许发送时就发送，不允许发送的时候等待，并且根据网络的情况调整窗口大小（广播信息）
TCP/UDP区别
- TCP面向连接, UDP面向非连接(发送数居前无需创建链接)
- 面向连接是通信前, 确认双方链路是否可达(请求前的三次握手, 断链接的 四次挥手)
- 面向非连接, 通信之前不去确认链路是否可达
- TCP提供安全可靠的数据传输服务, UDP不保证传输的数据的可靠性
- TCP面向字节流, UDP面向报文
- TCP传输速度慢, UDP传输数据快(实际上现在TCP并不比UDP慢多少)
- TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道
TCP的三次握手/四次挥手
1. 三次握手
- 第一次握手, 客户端发送 SYN seq=x 请求报文到服务端, 并且等待响应, 自身状态为 SYN_SEND
- 第二次握手, 服务端收到 SYN 报文段, 返回 ACK = x+1, SYN seq=y 报文段, 自身状态为 SYN_RCVD
-
第三次握手, 客户端收到 SYN_ACK 报文段, 返回 ACK = y+1, 客户端和服务端都进入ESTABLISHED状态
TCP三次握手.png
第一握手SYN.png
第二次握手SYN+ACK.png
第三次握手ACK.png
2. 数据传输
客户端发送 seq ACK
服务端返回 ACK
3. 四次挥手
四次挥手.png
- 客户端和服务端都可以关闭链接, 一般都是客户端主动发起关闭
- 如果是客户端发起 传送 FIN给服务端, 服务端返回 ACK
- 如果是服务端发起 传送 FIN给客户端, 客户端返回 ACK
4. SYN攻击
在三次握手过程中，服务器发送SYN-ACK之后，收到客户端的ACK之前的TCP连接称为半连接，如果这时候发起大量的SYN请求，却不响应ACK请求，会打配大量TCB（Transmission Control Block）消耗系统资源，导致服务器有大量SYN_RECV状态
解决方案：
-
无效连接的监视释放：监视系统的半开连接和不活动连接，当达到一定阈值时拆除这些连接 -
延缓TCB分配方法：当SYN数据报文一到达，系统立即分配TCB，从而占用了资源，延迟到建立连接了再分配TCB -
Syn Cache技术：收到一个SYN报文时，在一个专用HASH表中保存这种半连接信息，直到收到正确的回应ACK报文再分配TCB，保存序列号 -
Syn Cookie技术：特殊的算法生成Sequence Number，看其是否与对方回应报文中的（Sequence Number-1）相同，从而决定是否分配TCB资源
连接队列：
在外部请求到达时，被服务程序最终感知到前，连接可能处于SYN_RCVD状态或是ESTABLISHED状态，但还未被应用程序接受。如果这两个队列满了之后，就会出现各种丢包的情形
半连接队列 sync queue-
全连接队列 accept queue
连接队列.png
TCP 长连接/短连接
由于每次链接的建立和断开都需要消耗资源/时间, 才引入了长连接/短连接概念
短连接：创建链接->数据传输->关闭链接...创建链接->数据传输->关闭链接...
数据交互少, 连接量大(HTTP对外提供的服务就是采用短连接)
长连接：创建链接->数据传输->(保持链接)->数据传输->关闭链接
连接数可控, 数据持续, 操作频繁, 可以节约建立/断开操作时间(数据库/文件服务器等...)
1. HTTP 1.0 长短连接
HTTP是不支持长连接的，都是由TCP来支持
HTTP只是请求/响应，长连接复用的是TCP层的连接
因此，虽然WEB的HTTP是短请求，但是TCP连接层是可以复用
短轮询，客户端不断的轮询请求服务端，服务端立即做出响应
长轮询，客户端不断的轮询请求服务端，服务端会根据一定的规则，给出响应（可能时立即的，可能是延迟的）
存在head of line blocking，当第一个request没有response，会block后续request
HTTP1.0 默认不支持长连接，设置header里面的Connection:keep-alive可以支持长连接
HTTP1.1 默认支持长连接
要让HTTP支持长连接, 设置header里面的Connection:keep-alive, 但是单独客户端设置支持是不生效的, 需要双方都支持才生效，并且连接是有保持时间（在服务端设置）。在tomcat服务器上，有设置保持连接的最大连接数，超过限制后会强制关闭socket。服务端要控制长连接的个数和时长，否则会导致连接被恶意占用问题
现在对外暴露的HTTP服务默认都是支持长连接的
但是在移动app端，由于app端的请求比较分散且时间跨度相对较大
这种短时间内的长连接效用不大
1. 基于tcp的长连接
2. http-pooling
3. http-streaming
4. websocket
keepalive在TCP层是检查TCP连接是否存活，在HTTP层是延长TCP连接的时长
2. HTTP 2.0
- 新的二进制格式（binary format） =
[Length + Type + Flags + Stream ID + Payload] - 使用
stream id还实现连接共享/多路复用，多个请求(stream)公用一个连接，每个stream的frame可以混合传输通过stream id查找对应的request - 可以在不断开连接的前提下取消某个request的stream
- header压缩
- Server push服务推送
- Flow Control流量控制
- 更安全的SSL
TCP/IP协议
- 数据链路层(MAC地址)
- 网络层(IP地址)
- IP协议 识别IP网段
- ARP协议 用IP地址换MAC地址
- 路由协议 跨网段
- 传输层(端口)
- 识别对应的应用
- 应用层(数据规格)
- 方便数据解析
网络地址分类
- A类地址: 1.0.0.0-127.255.255.255/8
- B类地址: 128.0.0.0-255.255.255.0/16
- C类地址: 192.0.0.0-233.255.255.255/24
主机域名解析流程
查缓存 -> 查本地hosts -> 查DNS服务器
浏览器缓存 -> 操作系统缓存 -> 路由器缓存 -> ISP的DNS域名缓存 -> 根域名服务器
- 浏览器缓存：浏览器会按照一定的频率缓存DNS记录
- 操作系统缓存：如果浏览器缓存中找不到需要的DNS记录，那就去操作系统中找。
- 路由缓存：路由器也有DNS缓存
- ISP的DNS服务器：ISP是互联网服务提供商(Internet Service Provider)的简称，ISP有专门的DNS服务器应对DNS查询请求
- 根服务器：ISP的DNS服务器还找不到的话，它就会向根服务器发出请求，进行递归查询（DNS服务器先问根域名服务器.com域名服务器的IP地址，然后再问.com域名服务器，依次类推）
正向代理和反向代理
1. 正向代理
[client(n) ->squid] ->server(1)
出口网关会采用正向代理将内部所有服务器发起的请求都指向到外部服务暴露的唯一IP地址
代理和客户端属于一个网段, 但是会隐藏真是用户的信息, 正向代理服务器对外暴露最好要做安全认证和授权
2. 反向代理
client(n) ->[nginx ->server(n)]
入口网关会采用反向代理来减轻服务端压力
代理和服务端属于一个网段
2.1 nginx
- 设置服务端的代理http版本为1.1时, 接受keepalive长连接配置
- 当代理服务器连接到上游服务器最大并发keepalive连接数, 超过次数时使用 LUR 关闭连接
- 设置代理服务器一个keepalive连接允许送达的最大请求数, 如果这个连接的请求书超过限制, 直接关闭连接
网友评论