网络

最新推荐文章于 2023-10-17 10:00:00 发布

qinjunu

最新推荐文章于 2023-10-17 10:00:00 发布

阅读量236

点赞数

分类专栏： Java

本文链接：https://blog.csdn.net/qj970514/article/details/104143591

版权

Java 专栏收录该内容

16 篇文章 0 订阅

订阅专栏

TCP/IP

TCP简介

OSI（概念型框架）的实现：TCP/IP

面向连接的，可靠的，基于字节流的传输层通信协议
将应用层的数据流分割成报文段并发送给目标节点的TCP层
数据包都有序号，对方收到则发送ACK确认，未收到则重传
使用校验和来检验数据在传输中是否有误

TCP Flags

URG：紧急指针标志
ACK：确认序号标志
PSH：push标志
RST：重置连接标志
SYN：同步序号，用于建立连接过程
FIN：finish标志，用于释放连接

TCP的三次握手

第一次握手：建立连接时，客户端发送SYN包（seq=x）到服务器，并进入SYN_SEND状态，等待服务器确认
第二次握手：服务器收到SYN包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN（seq=y），即SYN+ACK包，此时服务器进入SYN_RECV状态
第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK（ack=y+1），此时发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手

为什么需要三次

为了初始化Sequence Number的初始值（通信双发要互相通知自己的Sequence Number初始值，作为今后的数据通信，保证接收到的数据不会因为通信问题而乱序，因此第二次握手之后客户端要向服务器告知已知到其序列号）

首次握手的隐患-SYN超时

问题起因分析：

Server收到Client的SYN，回复的SYN_ACK的时候未收到确认
Server不断重试直至超时，Linux默认5次，每次时间翻倍（1，2，4，8，16，32）

针对SYN Flood的防护措施

SYN队列满后，通过tcp_syncookies参数回发SYN Cookie
若正常连接则client会回发SYN Cookie，直至建立连接

建立连接后，Client出现故障：保活机制

向对方发送保活探测报文，如果未收到响应则继续发送
尝试次数达到保活探测数仍未响应则中断连接

TCP四次挥手

为什么会与TIME_WAIT状态（2MSL（Maximum Segment Lifetime）：报文最大生存时间）

确保有足够的时间让对方收到ACK包
避免新旧连接混淆

为什么需要四次

因为全双工，发送方和接收方都需要FIN报文和ACK报文

服务器出现大量CLOSE_WAIT状态的原因

对方关闭socket连接，我方忙于读或写，没有及时关闭连接

解决

检查代码，特别是释放资源的代码
检查配置，特别是处理请求的线程配置

TCP的滑动窗口

RTT和RTO

RTT：发送一个数据包到收到对应的ACK，所花费的时间
RTO：重传时间间隔

TCP使用滑动窗口做流量控制与乱序重排

保证TCP的可靠性
保证TCP的流控特性

UDP

面向非连接
不维护连接状态，支持同时向多个客户端传输相同的消息
数据包报头只有8个字节，额外开销较小
吞吐量只受限于数据生成速率，传输速率以及机器性能
尽最大努力交付，不保证可靠交付，不需要维持复杂的链接状态表
面向报文，不对应用程序提交的报文信息进行拆分或者合并

TCP和UDP的区别

面向连接 vs 无连接
可靠性（确认重传机制）
有序性
速度
量级

HTTP

超文本传输协议HTTP特点（应用层）

支持客户/服务器模式
简单快速
灵活（允许任何数据类型）
无连接（每次仅处理一个请求）
无状态（没有记忆能力）

请求结构
请求/响应步骤

客户端连接到Web服务器
发送HTTP请求
服务器接受请求并返回HTTP响应
释放TCP连接
客户端浏览器解析HTML内容

在浏览器地址栏键入URL，按下回车之后经历的流程

DNS解析
TCP连接
发送HTTP请求
服务器处理请求并返回HTTP报文
浏览器解析渲染页面
连接结束

HTTP状态码

1xx：指示信息–表示请求已接收，继续处理
2xx：成功–表示请求已被成功接收，理解，接受
3xx：重定向–要完成请求必须进行进一步的操作
4xx：客户端错误–请求有语法错误或请求无法实现
5xx：服务器端错误–服务器未能实现合法的请求

常见

200：正常返回信息
400：客户端请求有语法错误，不能被服务器所理解
401：请求未经授权，这个状态代码必须和www-Authenticate报头一起使用
403：服务器收到请求，但是拒绝提供服务
404：请求资源不存在，如输入错误的url
500：服务器发生不可预期的错误
503：服务器当前不能处理客户端的请求，一段时间后可恢复正常

GET和POST请求的区别

从三个层面来解答

HTTP报文层面：GET将请求信息放在URL（键值对），POST放在报文体中
数据库层面：GET符合幂等性（对数据库的一次操作和多次操作获得的结果是相同的）和安全性（对数据库的操作没有改变数据库中的数据–查询），POST不符合（会往数据库中提交数据）
其他层面：GET可以被缓存，被存储，而POST不行

Cookie和Session的区别

Cookie

是由服务器发给客户端的特殊信息，以文本的形式存放在客户端
客户端再次请求的时候，会把Cookie回发
服务器接收到后，会解析Cookie生成与客户端相对应的内容

Session

服务器端的机制，在服务器上保存的信息
解析客户端请求并操作session id，按需保存状态信息

区别

Cookie数据存放在客户的浏览器上，Session数据放在服务器上
Session相对于Cookie更安全
若考虑减轻服务器负担，应当使用Cookie

HTTP和HTTPS的区别

SSL（Security Sockets Layer，安全套接层）

为网络通信提供安全及数据完整性的一种安全协议
是操作系统对外的SPI，SSL3.0后更名为TLS
采用身份验证和数据加密保证网络通信的安全和数据的完整性

加密的方式

对称加密：加密和解密都使用同一个密钥
非对称加密：加密使用的密钥和解密使用的密钥是不相同的（私钥，公钥）
哈希算法：将任意长度的信息转换为固定长度的值，算法不可逆
数字签名：证明某个信息或者文件是某人发出/认同的

HTTPS数据传输流程

浏览器将支持的加密算法信息发送给服务器
服务器选择一套浏览器支持的加密算法，以证书的形式回发浏览器
浏览器验证证书合法性，并结合证书公钥加密信息（共享密钥，之后以共享密钥交互信息）发送给服务器
服务器使用私钥解密信息，验证哈希，加密响应消息回发浏览器（服务器同意用共享密钥）
浏览器解密响应信息，并对消息进行验证，之后进行加密交互数据