java面试——计算机网络

时间 2019-11-19

标签 java 面试计算机网络栏目 Java 繁體版

原文原文链接

目录html

网络分层
TCP和UDP的区别
TCP的三次握手和四次挥手
TCP滑窗（好麻烦，上课的时候听得就懵，出来混，老是要还的）
Http协议
Https与Http的区别

好文推荐：java

网络分层

（OSI开放式互联参考模型）web

七层面试

第1层物理层

　　机械、电子、定时接口通讯信道上的原始比特流传输算法

　　解释：首先要解决两台物理机之间的通讯需求，机器A--->机器B发送比特流浏览器

　　（物理层主要定义了物理设备的标准，如网线的类型，光纤的接口，传输比特流（0/1）转换为电流强弱，到达目的地后，再转换为0/1机器码（网卡工做在这一层））缓存

第2层数据链路层

物理寻址、同时将原始比特流转变为逻辑传输线路安全

第3层网络层

控制子网的运行，如逻辑编址、分组传输、路由选择服务器

TCP和UDP的区别

　　首先须要知道TCP和UDP是什么，才能更好的理解二者之间的区别微信

TCP---传输控制协议

　　提供的是面向链接、可靠的基于字节流的传输层通讯协议。当客户和服务器彼此交换数据前，必须先在双方之间创建一个TCP链接，以后才能传输数据。TCP提供超时重发，丢弃重复数据，检验数据，流量控制等功能，保证数据能从一端传到另外一端。

　　将应用层的数据流分割成报文段并发送给目标节点的TCP层

　　数据包都有序号，对方收到则发送ACK确认，未收到则重传

　　使用校验来检验数据在传输过程当中是否有误

UDP---用户数据报协议

　　是一个简单的面向数据报的运输层协议。UDP不提供可靠性，它只是把应用程序传给IP层的数据报发送出去，可是并不能保证它们能到达目的地。因为UDP在传输数据报前不用在客户和服务器之间创建一个链接，且没有超时重发等机制，故而传输速度很快。

特色：

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

区别

链接性：TCP面向链接（如打电话要先拨号创建链接）；UDP是无链接的，即发送数据以前不须要创建链接
可靠性：TCP提供可靠的服务。也就是说，经过TCP链接传送的数据，无差错，不丢失，不重复，且按序到达；UDP尽最大努力交付，即不保证可靠交付。Tcp经过校验和，重传控制，序号标识，滑动窗口、确认应答实现可靠传输。如丢包时的重发控制，还能够对次序乱掉的分包进行顺序控制。
实时性：UDP具备较好的实时性，工做效率比TCP高，适用于对高速传输和实时性有较高的通讯或广播通讯。
传输方式：每一条TCP链接只能是点到点的；UDP支持一对一，一对多，多对一和多对多的交互通讯
资源：TCP对系统资源要求较多，UDP对系统资源要求较少。

应用场景

　　普通的会议视频图像，固然首选UDP，毕竟丢几包无所谓。
　　传输文件等，不能丢包，用TCP

TCP三次握手和四次挥手

Tcp三次握手

　　确认序号标志ACK：当ACK=1时，确认字段才有效。当ACK=0时，确认号无效。TCP规定，在链接创建后全部传送的报文段都必须把ACK置1。
　　同步序号SYN：在链接创建时用来同步序号。当SYN=1而ACK=0时，代表这是一个链接请求报文段。对方若赞成创建链接，则应在响应的报文段中使SYN=1和ACK=1。故SYN置为1，就表示这是一个链接请求和链接接收报文。
　　序列号seq：当发送一个数据时，数据是被拆成多个数据包来发送，序列号就是对每一个数据包进行编号，这样接受方才能对数据包进行再次拼接。
　　下一个数据包的编号ack：这也就是为何第二请求时，ack是seq+1

　　FIN：finish标志，用于释放链接

整个流程为：

创建链接时，，客户端发送SYN包（syn=j），而后进入SYN_SEND状态，等待服务器确认（确认客户端具备发送功能）
服务器收到SYN包，必须确认客户的SYN（ackj+1）,同时本身也发送一个SYN包（syn=k），即SYN+ACK包，进入SYN_RECV状态，这个状态被称为半链接状态（确认服务端具备接收和发送功能）
客户端再进行一次确认，收到服务器的SYN+ACK包，向服务器发送确认包ACK（ack=k+1）,此包发送完毕，客户端和服务器进入ESTABLISHED状态（确认客户端具备接收功能）

注意：面试时解释尽可能不要用白话（A：喂，你听到了吗），对专业人员，要使用专业术语！

通俗解释：

客户端首先要SYN=1,表示要建立链接，
服务端接收到后，要告诉客户端：我接受到了！因此加个ACK=1，就变成了ACK=1,SYN=1
理论上这时就建立链接成功了，因此客户端要再发一个消息给服务端确认一下，这时只须要ACK=1就好了。

为何要进行三次握手，而不是两次？

　　首次握手隐患——SYN超时

　　问题原由分析：

　　　　Server收到Client的SYN，回复SYN-ACK的时候未收到ACK确认

　　　　Server不断重试直至超时，Linux默认等待63秒才断开链接，在此期间服务器可能会遭到SYN Flood的防御措施，攻击者就会将队列中 SYN耗尽，让其余的正常链接没法处理

　　针对SYN Flood的防御措施

　　　　SYN队列满后，经过tcp_syncookies参数回发SYN Cookie

　　　　若为正常链接则Client会回发SYN Cookie，直接创建链接

　　举个例子：

　　假设客户端和服务器进行TCP链接，而后第一次发送的TCP链接请求发生了阻塞。

　　因而因为客户端没有收到服务器的应答报文，客户端认为这个TCP链接请求丢失了，因而从新发送了TCP链接请求。此次没有阻塞，成功链接了，由于是讨论的两次握手，因此只进行两次链接就能够进行通讯了。

　　通讯结束，而后就断开了链接。

　　这时候最开始的阻塞的链接请求A客户端觉得丢失了，可是没有丢失，只是阻塞了而已，阻塞一段时间网络又畅通了，因而TCP链接请求A成功到达了服务器，服务器又觉得是客户端又要进行数据传输，因而服务器就又对这个链接请求进行应答，两次握手，因而又成功创建了TCP链接。

　　可是因为客户端它觉得这个链接请求已经丢失了，因此不会利用这个创建的链接请求进行数据通讯，虽然服务器分配给了资源给客户端，可是客户端并不进行数据传输，服务端就等待客户端的响应，这样就白白浪费了服务器的资源，试想一下若是网络很拥堵，那么等网络变畅通之后，服务器岂不是浪费了一堆资源，可能对于正常的链接请求都没法处理了！

　　三次握手就能够避免资源浪费，只要客户端不回应服务端

　　服务器过了很长时间(规定好的时间和客户端)都没有收到回复，因而也不会为客户端分配资源，此次链接就放弃了。

小结：　　

两次握手，是由于服务器收到了客户端的消息，服务器知道了客户端是能够发送消息的，但因为没有第三次握手，因此服务器不知道客户端是否具备接受消息的能力;
客户端从服务器接受到了消息，客户端知道了服务器接受到了个人消息才回复，说明服务器的接受消息能力和发送消息的能力没问题(服务器发送出了消息);
综上所述，客户端确保了服务器的接受发送没问题，可是服务器仅仅只知道客户端的发送消息没问题，这并非可靠的，因此两次握手不能够。

总结：

　　三次握手确保服务端和客户端都具备发送和接收消息能力，这样就能够进行通话了(创建了TCP链接)

TCP四次挥手

　　Tcp三次握手是TCP创建链接的过程，Tcp四次挥手则是TCP链接释放的过程。

当客户端没有数据再须要发送给服务端时，就须要释放客户端的链接，这整个过程为：

客户端发送一个报文给服务端（没有数据），其中FIN设置为1，用来关闭Client到Server的数据传送，客户端进入FIN_WAIT_1状态（客户端Client发送FIN，用来关闭Client到Server的数据传送）
服务端收到来自客户端的FIN，发送一个ACK给客户端，确认序号为收到序号+1 ，（与SYN相同，一个FIN占用一个序号），服务端进入CLOSE_WAIT状态（此时TCP连接处于半关闭状态，即客户端已经没有要发送的数据了，但服务端若发送数据，则客户端仍要接收。）
服务端发送一个FIN给客户端，用来关闭服务端到客户端的数据传送，服务端进入LAST_ACK状态（服务端Server发送一个FIN，用来关闭Server到Client的数据传送）
客户端收到FIN后，进入TIME_WAIT状态，接着发送一个ACK给服务端，确认序号为收到序号+1，最后客户端和服务端都进入CLOSED状态

为何会有TIME_WAIT状态，不直接转换为CLOSED ？

确认有足够的时间让对方收到ACK包（若是被动关闭的那端没有收到ACK包，就会触发被动端重发FIN包，一来一去就是2MSL）
避免新旧链接混淆（由于有些路由器会缓存IP数据包，若是链接被重用了，就可能会跟新链接混在一块儿）

为何须要四次握手才能断开链接？

由于全双工，发送方和接收方都须要FIN报文和ACK报文

服务器出现大量CLOSE_WAIT状态的缘由

　　出现大量CLOSE_WAIT，只可能值客户端发送了FIN，服务端没有进一步发送ACK，或者FIN已经确认

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

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

TCP的滑动窗口

TCP的滑动窗口作流量控制与乱序重排

　　保证TCP的可靠性

　　保证TCP的流控特性

RTT和RTO

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

　　RTO：重传时间间隔

TCP使用滑动窗口作浏览控制

Http协议

特色

支持客户/服务器模式
简单快速
灵活
无链接

请求/响应的步骤：

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

　　以前历来没注意到的一个点，忽然想起以前某人说的，面试中遇到的一个问题：地址栏中输入URL会发生什么？

　　在这整个过程当中，大体能够分为如下几个过程

DNS域名解析：浏览器自己是一个客户端，当你输入URL的时候，首先浏览器会去请求DNS服务器（从近及远，浏览器缓存、路由器缓存、IPS服务器缓存、域名服务器缓存，顶级域名服务器，还有一个缓存没听清），经过DNS获取相应的域名对应的IP
TCP链接：而后经过IP地址找到IP对应的服务器后，要求创建TCP链接
HTTP请求：浏览器发送完HTTP Request（请求）包后，服务器接收到请求包以后才开始处理请求包
服务器处理请求返回HTTP响应：在服务器收到请求以后，服务器调用自身服务，返回HTTP Response（响应）包
浏览器页面渲染：客户端收到来自服务器的响应后开始渲染这个Response包里的主体（body）
关闭链接：等收到所有的内容随后断开与该服务器之间的TCP链接。

　　当咱们在浏览器地址栏上输入要访问的URL后，浏览器会分析出URL上面的域名，而后经过DNS服务器查询出域名映射的IP地址，浏览器根据查询到的IP地址与Web服务器进行通讯，而通讯的协议就是HTTP协议。

HTTP状态码

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

常见的状态码

200 OK：客户端请求成功
301 Moved Permanently（永久移除）：请求的URL已经移走。Response中应该包含一个Location URL，说明资源如今所处的位置
302 found：重定向
400 Bad Request：客户端请求有语法错误，不能被服务器所理解
401 Unaythorized：请求未经受权，这个状态码必须和WWW-Authenticate报头域一块儿使用
403 Forbidden：服务端禁止访问该资源
404 Not Found：请求资源不存在，输入了错误的URL
500 Internal Server Error：服务器发生了不可预期的错误
503 Server Unavaliable：服务器当前不能处理客户端的请求，一段时间后可能恢复正常

HTTP中重定向和转发的区别

　　本质区别：转发是服务器行为，重定向是客户端行为

　　重定向：两次请求，浏览器地址发生变化，可访问自身web以外的资源，传输的数据会丢失

　　请求转发：一次请求，地址不变，访问自身web资源，传输的数据不会丢失

GET请求和POST请求的区别

GET将请求信息放在URL，POST放在报文体
- GET请求的数据会附在URL以后，以?分割URL和传输数据，参数之间以&相连
- POST请求把提交的数据放放再HTTP包的包体中
GET提交的数据最多只能是1024字节，理论上POST没有限制
POST的安全性要比GET高
- 经过GET提交数据，那么用户名和密码将出如今URL上，登陆页面也能被浏览器缓存，其余人查看浏览器的历史记录就可能拿到用户名和密码，除此以外，使用GET提交数据可能会形成Cross-site request forgery攻击

GET和POST两种基本请求方法的区别

Cookie和Session的区别

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

Cookie的设置以及发送过程

Session

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

Session的实现方式

使用Cookie来实现

　　2.使用URL回写来实现

　　服务器发送给浏览器全部页面都携带SessionId的参数，客户端点击任何一个链接，都会使SessionId带回给服务器，......

　 HTTP协议是构建在TCP/IP协议之上的，是TCP/IP协议的一个子集，因此要理解HTTP协议，有必要先了解下TCP/IP协议相关的知识。

不一样点：

不管客户端怎么设置，session都能正常工做，当客户端仅用cookie时将没法使用cookie
session可存储任意的java对象，cookie只能存储String类型的对象

TCP/IP的分层管理

　　TCP/IP协议族包含了不少协议，按层次分有四层：应用层、传输层、网络层、数据链路层。

应用层：包含了各类通用的应用服务，好比 FTP（File Transfer Protocol，文件传输协议）、DNS、HTTP等。
传输层：提供网络中两台计算机之间的数据传输，好比TCP、UDP。
网络层：处理在网络上流动的数据包，该层规定了传输路线，数据包经过怎样的路径传送到对方的计算机中。好比 IP。
数据链路层：链接网络的硬件部分，包括网卡，光纤等等硬件设备

TCP/IP模型与OSI模型对比

HTTP、TCP/IP、DNS之间的关系

　　当客户端访问Web站点时，首先会经过DNS服务查询到域名的IP地址。而后浏览器生成HTTP请求，并经过TCP/IP协议发送给Web服务器。Web服务器接收到请求后会根据请求生成响应内容，并经过TCP/IP协议返回给客户端。

Https与Http的区别

Http协议运行在TCP之上，用来在 Internet 上传送超文本的传送协议，它可使浏览器更加高效，使网络传输减小。但 HTTP 协议采用明文传输信息，客户端与服务器端都没法验证对方的身份，存在信息窃听、信息篡改和信息劫持的风险。；

Https是身披SSL(Secure Socket Layer)外壳的Http，运行于SSL上，SSL运行于TCP之上，是添加了加密和认证机制的HTTP。两者之间存在以下不一样：

端口不一样：Http与Https使用不一样的链接方式，。用的端口也不同，前者是80，后者是443
资源消耗：和Http通讯相比，Https通讯会因为加减密处理消耗更多的CPU和内存资源；
开销：Https通讯须要到CA机构申请SSL证书，而证书通常须要向认证机构购买；
安全性：Http无状态传输，HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议（HTTPS=HTTP+加密+认证+完整性保护），要比Http协议安全。
传输方式：Http明文传输，Https是密文传输

加密方式

对称密钥加密：指加密和解密使用同一个密钥的方式

　　这种方式存在的最大问题就是密钥发送问题，即如何安全地将密钥发给对方；

非对称加密：指使用一对非对称密钥，即公钥和私钥，公钥能够随意发布，但私钥只有本身知道。

　　发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用本身的私钥进行解密。
　　因为非对称加密的方式不须要发送用来解密的私钥，因此能够保证安全性；可是和对称加密比起来，它很是的慢，因此咱们仍是要用对称加密来传送消息，但对称加密所使用的密钥咱们能够经过非对称加密的方式发送出去。

哈希算法：将任意长度的信息转换为固定的长度的值，算法不可逆
数字签名：证实某个消息或者文件时某人发出/认同的

Https的加密机制是一种共享密钥加密和公开密钥加密并用的混合加密机制。

HTTPS数据传输流程

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

Https真的很安全嘛？

　　不必定

浏览器默认填充http://，https->http请求须要进行跳转，有被劫持的风险　
可使用HSTS（HTTP Strict Transport Security）优化

Socket简介

　　两个进程须要进行通讯，最基本的前提可以惟一的标识一个进程

　　在本地进程通讯中，使用pid来标识一个进程，可是pid只在本地惟一，网络中两个进程的pid的冲突可能性是比较高的

　　因此须要另辟蹊径，ip层的ip地址能够惟一标识一台主机，而TCP协议和端口号能够惟一标识主机的一个进程

　　——>>能够利用IP地址+TCP协议+端口号来惟一标识网络的一个进程，就可使用socket进行通讯

Scoket是TCP/IP协议的抽象（socket的出现只是为了更好的使用TCP/IP协议），是操做系统对外开放的接口

Socket的通讯流程

socket相关面试题

　　编写一个网络应用程序，有客户端和服务器端，客户端向服务器发送一个字符串，服务器收到该字符串后将其打印到命令行上，而后向客户端返回该字符串的长度，最后，客户端输出服务器端返回该字符串的长度，分别用TCP和UDP两种方式实现

本文转发整合：