java面试——计算机网络

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

好文推荐：

网络分层

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

七层

第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两种方式实现

本文转发整合：