计算机网络、计算机操作系统这两个“兄弟”是所有开发岗位都需要“结拜”的,不管你是 Java、C++还是测试。对于后端开发的童鞋来说,计算机网络的重要性不亚于语言基础,毕竟平时开发经常会和网络打交道,比如:抓个包等等。所以对这一块知识点的准备还是要抱着敬畏之心,不要放过任何一个漏网之题。下面分享下我的学习过程:
学习计算机网络时我们一般采用折中的办法,也就是中和 OSI 和 TCP/IP 的优点,采用一种只有五层协议的体系结构,这样既简洁又能将概念阐述清楚。
计算机五层网络体系中涉及的协议非常多,下面就常用的做了列举:
如何保证UDP的可靠连接?
三次握手
TCP 建立连接的过程叫做握手,握手需要在客户和服务器之间交换三个 TCP 报文段。最初客户端和服务端都处于 CLOSED(关闭) 状态。本例中 A(Client) 主动打开连接,B(Server) 被动打开连接。
一开始,B 的 TCP 服务器进程首先创建传输控制块TCB,准备接受客户端进程的连接请求。然后服务端进程就处于 LISTEN(监听) 状态,等待客户端的连接请求。如有,立即作出响应。
为了防止已经失效的连接请求报文段突然又传送到了 B,因而产生错误。比如下面这种情况:A 发出的第一个连接请求报文段并没有丢失,而是在网路结点长时间滞留了,以致于延误到连接释放以后的某个时间段才到达 B。本来这是一个早已失效的报文段。但是 B 收到此失效的链接请求报文段后,就误认为 A 又发出一次新的连接请求。于是就向 A 发出确认报文段,同意建立连接。
对于上面这种情况,如果不进行第三次握手,B 发出确认后就认为新的运输连接已经建立了,并一直等待 A 发来数据。B 的许多资源就这样白白浪费了。
如果采用了三次握手,由于 A 实际上并没有发出建立连接请求,所以不会理睬 B 的确认,也不会向 B 发送数据。B 由于收不到确认,就知道 A 并没有要求建立连接。
双方通信无误必须是两者互相发送信息都无误。传了 SYN,证明发送方到接收方的通道没有问题,但是接收方到发送方的通道还需要 ACK 信号来进行验证。
据传输结束后,通信的双方都可以释放连接。现在 A 和 B 都处于 ESTABLISHED 状态。
当服务器执行第二次挥手之后, 此时证明客户端不会再向服务端请求任何数据, 但是服务端可能还正在给客户端发送数据(可能是客户端上一次请求的资源还没有发送完毕),所以此时服务端会等待把之前未传输完的数据传输完毕之后再发送关闭请求。
停止等待协议是为了实现可靠传输的,它的基本原理就是每发完一个分组就停止发送,等待对方确认。在收到确认后再发下一个分组;在停止等待协议中,若接收方收到重复分组,就丢弃该分组,但同时还要发送确认。主要包括以下几种情况:无差错情况、出现差错情况(超时重传)、确认丢失和确认迟到、确认丢失和确认迟到。
TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率,保证接收方来得及接收。接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小,从而影响发送方的发送速率。将窗口字段设置为 0,则发送方不能发送数据。
在进行 Java NIO 学习时,可能会发现:如果客户端连续不断的向服务端发送数据包时,服务端接收的数据会出现两个数据包粘在一起的情况。
基于上面两点,在使用 TCP 传输数据时,才有粘包或者拆包现象发生的可能。一个数据包中包含了发送端发送的两个数据包的信息,这种现象即为粘包。 接收端收到了两个数据包,但是这两个数据包要么是不完整的,要么就是多出来一块,这种情况即发生了拆包和粘包。
拆包和粘包的问题导致接收端在处理的时候会非常困难,因为无法区分一个完整的数据包。
分包机制一般有两个通用的解决方法:
tips:UDP 没有粘包问题,但是有丢包和乱序。 不完整的包是不会有的,收到的都是完全正确的包。传送的数据单位协议是 UDP 报文或用户数据报,发送的时候既不合并,也不拆分。
Netty 是一个广泛使用的 Java 网络编程框架(Netty 在 2011 年获得了Duke’s Choice Award,见https://www.java.net/dukeschoice/2011)。它活跃和成长于用户社区,像大型公司 Facebook 和 Instagram 以及流行 开源项目如 Infinispan, HornetQ, Vert.x, Apache Cassandra 和 Elasticsearch 等,都利用其强大的对于网络抽象的核心代码。Netty
301,302 都是 HTTP 状态的编码,都代表着某个 URL 发生了转移。
区别:
Forward 和 Redirect 代表了两种请求转发方式:直接转发和间接转发。
举个通俗的例子:
直接转发就相当于:“A 找 B 借钱,B 说没有,B 去找 C 借,借到借不到都会把消息传递给 A”;
间接转发就相当于:“A 找 B 借钱,B 说没有,让 A 去找 C 借”。
客户端发送的 请求报文 第一行为请求行,包含了方法字段。
HTTP1.1 的主要变化:
优点:
缺点:
为了避免数据在传输过程中被替换,比如黑客修改了你的报文内容,但是你并不知道,所以我们让发送端做一个数字签名,把数据的摘要消息进行一个加密,比如 MD5,得到一个签名,和数据一起发送。然后接收端把数据摘要进行 MD5 加密,如果和签名一样,则说明数据确实是真的。
对称加密中,双方使用公钥进行解密。虽然数字签名可以保证数据不被替换,但是数据是由公钥加密的,如果公钥也被替换,则仍然可以伪造数据,因为用户不知道对方提供的公钥其实是假的。所以为了保证发送方的公钥是真的,CA 证书机构会负责颁发一个证书,里面的公钥保证是真的,用户请求服务器时,服务器将证书发给用户,这个证书是经由系统内置证书的备案的。