后台开发人员面试内容——计算机网络(五)

计算机网络

一、OSI七层网络协议：

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

五层体系机构：

应用层——传输层（TCP报文、UDP数据包）——网络层（IP数据报或分组）——数据链路层（帧）——物理层（比特流）

 

二、TCP和UDP的区别？

1.TCP是面向连接的，UDP面向无连接

2.TCP是可靠的连接，保证数据的正确性；UDP可能丢包

3.TCP连接只能是点到点的，UDP可以一对一，一对多，多对一和多对多交互通信

4.TCP传输速度慢，要求系统资源多，UDP传输速度快，要求系统资源少

5.FTP、HTTP、Telnet、SMTP、POP3、HTTPS是基于TCP的， DNS、SNMP、NFS是基于UDP的

 

三、TCP如何保证可靠性

1. 校验和: 发送方在发送数据之前计算检验和（ 发送的数据包的二进制相加然后取反），并进行校验和的填充。 接收方收到数据后，对数据以同样的方式进行计算，求出校验和，与发送方的进行比对。

注意：如果接收方比对校验和与发送方不一致，那么数据一定传输有误。但是如果接收方比对校验和与发送方一致，数据不一定传输成功

2. 流量控制( 滑动窗口协议)： TCP 连接的每一方都有固定大小的缓冲空间 ，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失

3.拥塞控制： 当

网络拥塞时，减少数据的发送

4. 超时重传：双方在发送一部分数据后，都会等待接收方发送的ACK报文，并解析ACK报文，判断数据是否传输成功，如果没有的接收到ACK报文的话，会重新发送请求

5. 重排序失序数据: TCP传输时将每个字节的数据都进行了编号，这就是序列号, 在传输的过程中，每次接收方收到数据后，都会对传输方发送ACK报文。

 

四、cookie 和session 的区别详解

1.cookie数据存放在客户的浏览器上，session数据放在服务器上。

2.cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗考虑到安全应当使用session。

3.session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能考虑到减轻服务器性能方面，应当使用COOKIE。

4.单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。

5.所以个人建议： 将登陆信息等重要信息存放为SESSION, 其他信息如果需要保留，可以放在COOKIE中

 

 

五、GET和POST本质上有什么区别

1.最直接的区别，GET请求的参数是放在URL里的，密码信息不要用Get方式发送请求，POST请求参数是放在请求body里的

2.GET请求的URL传参有长度限制，而POST请求没有长度限制

3.GET请求的参数只能是ASCII码，所以中文需要URL编码，而POST请求传参没有这个限制

4.GET能被缓存，POST不能被缓存

 

 

六、Http 与 Https 的区别

1.HTTP协议以明文方式发送内容，不提供任何方式的数据加密。HTTPS在HTTP的基础上加入了SSL/TLS协议，依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密；

2. http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

3. https协议需要到CA申请证书，一般免费证书较少，因而需要一定费用。

4. http的连接很简单，是无状态的；HTTPS协议是由SSL/TLS+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全

 

七、TCP/IP三次握手四次挥手

 图解如下：

SYN：同步序列编号（Synchronize Sequence Numbers）；

ACK：确认序列包

SYN_SENT ：(同步发送状态)

SYN_RECV：(同步接受状态)

ESTABLISHED：（TCP连接成功）

1.第一次握手：建立连接时，客户端发送syn包（syn=j）到服务器，并进入SYN_SENT（同步发送）状态，等待服务器确认；

2. 第二次握手：服务器收到syn包，必须确认客户的SYN（ACK =j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV（同步接受）状态；

3.第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ACK =k+1），此包发送完毕，客户端和服务器进入ESTABLISHED(建立连接)状态，完成三次握手。

问题：

为什么不能用两次握手进行连接(为什么TCP要发送最后一次确认)？

主要防止已经失效的连接请求报文突然又传送到了服务器， 两者两次握手后连接没有数据传输，造成资源浪费。

假设有这样一种场景，客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费

 

四次挥手-连接终止协议

 

1）客户端进程发出连接释放报文 (FIN )，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入终止等待1 (FIN-WAIT-1)状态。 

2）服务器收到连接释放报文(FIN),发出确认报文ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了关闭等待(CLOSE-WAIT )状态。服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个关闭等待(CLOSE-WAIT )状态持续的时间。

3）客户端收到服务器的确认请求后，此时，客户端就进入终止等待2(FIN-WAIT-2 )状态，等待服务器发送连接释放报文

4）服务器将最后的数据发送完毕后，就向客户端发送连接释放报文(FIN)，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了最后确认(LAST-ACK )状态，等待客户端的确认。

5）客户端收到服务器的连接释放报文(FIN)后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了时间等待(TIME-WAIT)状态。注意此时TCP连接还没有释放， 客户端等待 2MSL（最长报文段寿命)后，当客户端撤销相应的TCB后，才进入CLOSED状态。

6）服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

问题：

为什么连接的时候是三次握手，关闭的时候却是四次握手？

服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次

为什么客户端最后还要等待2MSL（最长报文段寿命 ）？

保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失 。如果丢失了，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器

如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75分钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。