计算机网络架构层面在宏观上来说
一般都是常考以下几种比如网络架构、通信握手的逻辑等
七层架构:
网络七层模型是一个标准,而非实现
网络四层模型由七层模型简化合并而来
四层架构:
TCP/IP 由四个层次组成:网络接口层、网络层、传输层、应用层。
网络接口层:使用某种协议与网络相连
网络层:使主机可以把分组发往任何网络,并使分组独立地传向目标。这些分组可能经由不同的网络,到达的顺序和发送的顺序也
可能不同。
传输层:源端和目的端机器上的对等实体可以进行会话。端到端的协议:传输控制协议(TCP)和用户数据报协议(UDP)。
应用层:包含所有的高层协议
TCP慢但是可靠
UDP快但是不可靠
TCP首部开销20字节;UDP的首部开销小,只有8个字节
TCP的逻辑通信信道是全双工的可靠信道,UDP则是不可靠信道
比如:
客户端向DNS服务器查询域名,一般返回的内容都不超过512字节,用UDP传输即可
主DNS上复制内容,一般超过512字节,用TCP传输
TCP 在传输之前会进行三次沟通,称为“三次握手”
传完数据断开的时候要进行四次沟通,称为“四次挥手”
第一次握手:主机 A 发送位码为 syn=1,随机产生 seq number=1234567 的数据包到服务器,主机 B 由 SYN=1 知道,A 要求建立联机;
第二次握手:主机 B 收到请求后要确认联机信息,向 A 发 送 ack number=( 主 机 A 的seq+1),syn=1,ack=1,随机产生 seq=7654321 的包
第三次握手:主机 A 收到后检查 ack number 是否正确,即第一次发送的 seq number+1,以及位码ack 是否为 1,若正确,主机 A 会再发送 ack number=(主机 B 的 seq+1),ack=1,主机 B 收到后确认seq 值与 ack=1 则连接建立成功
为什么要传回 SYN
接收端传回发送端所发送的 SYN 是为了告诉发送端,我接收到的信息确实就是你所发送的信号了
传了 SYN,为啥还要传 ACK
双⽅通信⽆误必须是两者互相发送信息都⽆误。传了 SYN,证明发送⽅到接收⽅的通道没有问题,但是接收⽅到发送⽅的通道还需要 ACK 信号来进⾏验证
TCP 四次握手
断开⼀个 TCP 连接则需要“四次挥⼿”:
1) 关闭客户端到服务器的连接:首先客户端 A 发送一个 FIN,用来关闭客户到服务器的数据传送,然后等待服务器的确认。其中终止标志位 FIN=1,序列号 seq=u
2) 服务器收到这个 FIN,它发回一个 ACK,确认号 ack 为收到的序号加 1。
3) 关闭服务器到客户端的连接:也是发送一个 FIN 给客户端。
4) 客户段收到 FIN 后,并发回一个 ACK 报文确认,并将确认序号 seq 设置为收到序号加 1。
首先进行关闭的一方将执行主动关闭,而另一方执行被动关闭
一个完整的业务可能会被TCP拆分成多个包进行发送,也有可能把多个小的包封装成一个大的数据包发
送,这个就是TCP的拆包和粘包问题
或者用这种解释也差不多:当发送包同时发送两个数据包时,接收包只收到了一个数据包,其中包含了两个数据包的信息,这种现象为粘包。当发送包同时发送两个数据包时,接收方也收到了两个数据包。但是这两个数据包,一个是不完整的,一个是多出来一块,这种现象为拆包。
主要的原因是:
可以通过设置该方法加以解决
详情可看我这篇文章
HTTP协议中 GET 和 POST的区别(全)
简单的说:
安全的 HTTP 方法不会改变服务器状态,也就是说它只是可读的。GET 方法是安全的,而 POST 却不是,因为 POST 的目的是传送实体主体内容,这个内容可能是用户上传的表单数据,上传成功之后,服务器可能把这个数据存储到数据库中,因此状态也就发生了改变
HTTPS 使用了隧道进行通信。通过使用 SSL,HTTPS 具有了加密(防窃听)、认证(防
伪装)和完整性保护(防篡改)
这也就导致了http的缺点有:
用户信息通过 Cookie 存储在用户浏览器中,也可以利用 Session 存储在服务器端,存储在服务器端的信息更加安全
一个 cookie 可以认为是一个「变量」,形如 name=value,存储在浏览器;一个
session 可以理解为一种数据结构,多数情况是「映射」(键值对),存储在服务器上。
具体的区别是:
Cookie和Session都是客户端与服务器之间保持状态的解决方案
实际上大多数的应用都是用Cookie来实现Session跟踪的,第一次创建Session的时候,服务端会在HTTP协议中告诉客户端,需要在Cookie里面记录一个Session ID,以后每次请求把这个会话ID发送到服务器,我就知道你是谁了。如果客户端的浏览器禁用了Cookie,会使用一种叫做URL重写的技术来进行会话跟踪,即每次HTTP交互,URL后面都会被附加上一个诸如sid=xxxxx这样的参数,服务端据此来识别用户,这样就可以帮用户完成诸如用户名等信息自动填入的操作了
Session 的主要作⽤就是通过服务端记录⽤户的状态。 典型的场景是购物⻋,当你要添加商品到购物⻋的时候,系统不知道是哪个⽤户操作的,因为 HTTP 协议是⽆状态的。服务端给特定的⽤户创建特定的 Session 之后就可以标识这个⽤户并且跟踪这个⽤户了。
Cookie 数据保存在客户端(浏览器端),Session 数据保存在服务器端。相对来说 Session 安全性更⾼。如果使⽤ Cookie 的⼀些敏感信息不要写⼊ Cookie 中,最好能将 Cookie 信息加密然后使⽤到的时候再去服务器端解密。
具体大致的流程是:
对称密钥加密(Symmetric-Key Encryption),加密和解密使用同一密钥
优点:运算速度快
缺点:无法安全地将密钥传输给通信方
非对称密钥加密,又称公开密钥加密(Public-Key Encryption),加密和解密使用不同的密钥。
公开密钥所有人都可以获得,通信发送方获得接收方的公开密钥之后,就可以使用公开密钥进行加密,接收方收到通信内容后使用私有密钥解密
优点:可以更安全地将公开密钥传输给通信发送方;
缺点:运算速度慢。
HTTPS 采用混合的加密机制,使用非对称密钥加密用于传输对称密钥来保证传输过程的安全性,之后使
用对称密钥加密进行通信来保证通信过程的效率
基于TCP的概念。因为TCP是无边界的流传输
数据链路层协议:
协议 | 名称 | 作用 |
---|---|---|
ARP | 地址解析协议 | 根据IP地址获取物理地址 |
RARP | 反向地址转换协议 | 根据物理地址获取IP地址 |
PPP | 点对点协议 | 主要是用来通过拨号或专线方式建立点对点连接发送数据,使其成为各种主机、网桥和路由器之间简单连接的一种共通的解决方案 |
网络层协议:
协议 | 名称 | 作用 |
---|---|---|
IP | 网际协议 | IP协议不但定义了数据传输时的基本单元和格式,还定义了数据报的递交方法和路由选择 |
ICMP | Internet控制报文协议 | ICMP就是一个“错误侦测与回报机制”,其目的就是让我们能够检测网路的连线状况,也能确保连线的准确性,是ping和traceroute的工作协议 |
RIP | 路由信息协议 | 使用“跳数”(即metric)来衡量到达目标地址的路由距离 |
IGMP | Internet组 管理协议 | 用于实现组播、广播等通信 |
应用层协议:
协议 | 名称 | 默认端口 | 底层协议 |
---|---|---|---|
HTTP | 超文本传输协议 | 80 | TCP |
HTTPS | 超文本传输安全协议 | 443 | TCP |
Telnet | 远程登录服务的标准协议 | 23 | TCP |
FTP | 文件传输协议 | 20传输和21连接 | TCP |
TFTP | 简单文件传输协议 | 21 | UDP |
SMTP | 简单邮件传输协议(发送用) | 25 | TCP |
POP | 邮局协议(接收用) | 110 | TCP |
DNS | 域名解析服务 | 53 | 服务器间进行域传输的时候用TCP,客户端查询DNS服务器时用 UDP |
文件上传漏洞,指的是用户上传一个可执行的脚本文件,并通过此脚本文件获得了执行服务端命令的能
力
文件上传的目录设置为不可执行。
1)判断文件类型。在判断文件类型的时候,可以结合使用MIME Type,后缀检查等方式。因为对于上
传文件,不能简单地通过后缀名称来判断文件的类型,因为攻击者可以将可执行文件的后缀名称改为图
片或其他后缀类型,诱导用户执行
2)限制上传文件的大小。
3)单独设置文件服务器的域名
状态码 | 类别 | 含义 |
---|---|---|
1XX | Informational(信息性状态码) | 接收的请求正在处理 |
2XX | Success(成功状态码) | 请求正常处理完毕 |
3XX | Redirection(重定向状态码) | 需要进行附加操作以完成请求 |
4XX | Client Error(客户端错误状态码) | 服务器无法处理请求 |
5XX | Server Error(服务器错误状态码) | 服务器处理请求出 |
更加详细的状态码可以通过阅读我这篇文章
里面有主要的状态码
RestTemplate的超全讲解(全)
65536
因为TCP的报文头部中源端口号和目的端口号的长度是16位,也就是可以表示216=65536个不同
端口号,因此TCP可供识别的端口号最多只有65536个。但是由于0到1023是知名服务端口,所以实际上还要少1024个端口号
rpc是本地调用一个远程函数
http是通过rul发送获取数据
rpc一般用在服务内部的相互调用,而http则用于和用户交互
区别点 | rpc | http |
---|---|---|
传输协议 | tcp、http | http |
性能消耗 | thrift高效的二进制传输 | json格式,比thrift更消耗 |
负载均衡 | 基本自带 | 需配置nginx以及HAProxy来实现 |
详情可看我之前的文章
【计算机网络】TCP为什么是三次握手,而不是两次或者四次的解析
【计算机网络】网络模型及协议
【计算机网络】HTTP1.0、HTTP1.1 和 HTTP2.0的详细分析