ICode9

精准搜索请尝试: 精确搜索
首页 > 编程语言> 文章详细

Inversion of Java Interview - 计算机网络篇

2021-07-09 15:30:40  阅读:194  来源: 互联网

标签:Inversion Java 请求 TCP 发送 Interview 数据 连接 客户端


Inversion of Java Interview-计算机网络篇

计算机网络面试准备,各方收集资料,来源于图书、视频、公众号、各大博客平台等。

1.OSI与TCP/IP各层的结构与功能,都有哪些协议

综合OSI和TCP/IP的优点,采用一种只有五层协议的体系结构,它包括物理层、链路层、网络层、传输层、应用层。

在这里插入图片描述

下面以为五层模型来说一说各层的作用

应用层

通过应用进程间的交互来完成特定网络应用。应用层定义协议定义的是应用进程间的通信和交互的规则,比如DNS,HTTP,SMTP协议等。把应用层交互的数据单元称为报文

也就是已经把数据传输到了电脑中,那么这个电脑中,数据到底是传输给那一个进程对应的应用程序,就是应用层来做的。

进程:主机中正在运行的程序。

DNS(Domain Name System,域名系统):它可以把域名和IP地址互相映射的一个分布式数据库。

HTTP(Hyper Text Transfer Protocol,超文本传输协议):所有WWW文件都必须遵守这个标准。

传输层

负责向两台主机进程之间的通信提供通用的数据传输服务。应用层利用该层传送应用层报文到其他的计算机。

通用的表示多个应用线程可以通过同一个传输层服务,实现传输层的复用分用的功能。所谓的复用表示多个应用层进程可同时使用下层传输层服务;分用表示传输层把信息分别交付到应用层中不同的进程中。

传输层主要使用TCP和UDP协议。

TCP,Transmission Control Protocol,传输控制协议:面向连接,实现可靠的数据传输服务。

UDP,User Datagram Protocol,用户数据报协议:面向无连接,提供尽最大努力的数据传输服务,不保证数据传输的可靠性。

网络层

在计算机网络中进行通信的两个计算机之间可能会有很多个数据链路,也可能要经过很多通信子网。网络层的任务就是选择合适的网间路由和交换节点,确保数据及时传达。

由IP找到具体的计算机地址,确保把打包的数据传输到指定的计算机。

在发送数据时,网络层把运输层产生的报文段或用户数据报封装成分组进行传输。在TCP/IP体系中,由于网络层使用IP协议,因此分组也叫IP数据报,简称数据报。

注意区分运输层的用户数据报UDP 和 网络层的IP数据包。

数据链路层

两台主机之间的数据传输,总是在一段一段的链路上传送的,这就需要专门的链路层协议。数据链路层将网络层的IP数据报组装成帧,在两个节点之间传输帧,每一帧包括数据和必要的控制信息(同步信息,地址信息,差错控制等)。其实这个帧也得交由物理层进行传输。

物理层

在物理层上传输的单位是比特。物理层的作用是把数据链路层的帧转换为对应的比特,再实现两个计算机节点之间比特流的透明传输,尽可能屏蔽掉具体传输介质和物理设备的差异。

2.TCP的三次握手和四次挥手

参考:https://blog.csdn.net/qzcsu/article/details/72861891

TCP把连接作为最基本的对象,每一条TCP连接都有两个端点。查看TCP报文段组成:

在这里插入图片描述

三次握手

第一次握手:Client将同步位SYN=1,随机产生一个seq=x,并将该数据发送给Server,Client进入SYN_SENT状态,等待Server确认。不能携带数据。

第二次握手:Server收到数据包后由同步位SYN=1知道Client请求建立连接,为该TCP连接分配缓存和变量。Server将同步位SYN和ACK都置为1,ack=x+1,随机产生一个seq=y,并将数据包发送给Client以确认连接请求,Server进入SYN_RCVD状态。不能携带数据。

第三次握手:Client收到确认后,为该TCP连接分配缓存和变量,并给B发出确认。SYN=1,ACK=y+1,seq=x+1,Client和Server都进入ESTABLISHED。这时可以携带数据。

在这里插入图片描述

为什么要传回SYN,ACK

SYN,ACK是TCP/IP建立连接时使用的握手信号,SYN(synchronization)

SYN:接收端传回发送端所发送的SYN是告诉发送端,它接收到的信息确实是接收端所发送的信息。

ACK

第一次回传:接收方发送数据到发送方还需要ACK来确认。

第二次回传:防止已经失效的连接请求报文突然又传送到服务器,产生错误。

四次挥手

第一次挥手:Client发送FIN=1和seq=u,用来关闭Client到Server的数据传输,Client进入DIN_WAIT_1状态。发送的数据序号是u。

第二次挥手:Server收到FIN=1后,发送ACK=1、ack=u+1和seq=v,表示已收到关闭请求。Server进入CLOSE_WAIT状态。此时TCP连接处于半关闭状态,即客户端已经没有要发送数据了,但服务器若发送数据,则客户端仍要接收。

第三次挥手:Server发送一个FIN,用来关闭Server到Client的数据传送,Server进入LAST_ACK状态。

第四次挥手:Client收到FIN后,Client进入TIME_WAIT状态,接着发送一个ACK=1给Server,确认序号ack=w+1,Server进入CLOSED状态。

在这里插入图片描述

3.为什么TCP连接需要三次握手,两次行不行?

为了防止已失效的连接请求报文突然又传送到了服务端,因而产生错误。

客户端发送的连接请求可能以为网络原因长时间滞留,之前的连接关闭后才到达Server,此时Server会认为是Client的连接请求,如果是两次握手,那么这里Server就已经建立好了TCP来连接,浪费性能。若采用三次握手,在这种情况下,由于Server端没有收到来自客户端的确认,则就会知道Client并没有请求建立连接,就不会建立连接。

4.为什么建立连接是三次握手,关闭是四次挥手

建立连接的时候,服务器处于LISTEN状态下,收到建立TCP连接请求SYN后,把ACK和SYN放在一个报文段里面发送给客户端。

而在关闭连接时,服务器收到对方的发送FIN报文时,仅仅表示此时客户端不再发送数据了,而自己的数据未必全部发送,所以己方又两个选择(立即关闭或继续发送未发送完毕的数据),发送ACK报文给对方表示同意关闭TCP连接,之后再把数据和FIN报文发送到客户端,因此,己方ACK和FIN一般会分开发送,从而导致多了一次。

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

TCP设有一个保活计时器(keep-live),服务器端每收到一次客户端的请求后都会重新复位这个计时器,时间通常设置为2h,若两小时为收到客户端任何的数据,服务器端就会发送一个探测报文段,以后每隔75s发送一次,若连续发送10个报文段都没有响应,服务器端就认为客户端出现了故障,直接关闭连接。

6.为什么客户端最后还要等待2MSL

MSL,Maximum Segment Lifetime,TCP允许设置不同的MSL。

为实现TCP这种双工连接的可靠释放

保证客户端发送的最后一个ACK能够到达服务器(不能到达,服务器等待回应造成资源浪费)。对服务器来说,它发送ACK+FIN报文请求断开了,客户端一直没有回复(可能是网络延迟),它就会重新发送一次FIN,等待确认。

为使旧的数据包在网络中因过期而消失

每个具体TCP实现必须选择一个报文段最大生存时间MSL,它是任何报文段被丢弃前在网络内的最长时间,一来一回就是2MSL。

7.TCP真的可靠吗

等价于:当TCP服务器宕机,会怎么样

TCP提供一种面向连接的、可靠的字节流服务。面向连接意味着有两个使用TCP的应用(通常是一个客户端和一个服务器)。从两个方面回答:TCP如何保证传输可靠性、TCP并不能保证数据传输可靠。

7.1 TCP如何保证传输可靠性

RTT:Round-Trip Time,循环时间

以字节为单位的滑动窗口

就是发送方的窗口分为已发送未确认、和待发送的数据(数据使用序号标记,数据顺序即序号顺序),接收方的窗口分为未按序收到、待接收数据。发送方的已发送未确认数据要等到接收方的确认后才从TCP缓存中删除。

超时重传

发送方在规定时间内没有收到接收方的确认就重新发送已发送的报文段。TCP采用自适应算法确认重传时间RTT新的RTTs = (1-a)*(旧的RTTs)+a*(新的RTT样本)

选择确认SACK

在序号机制顺序传输时,接收方接收到的序号可能是间断的,他就把这些间断的数据都收下,之后再接收缺失的数据。接收到重复的数据时,能够对重复的数据进行丢弃。

7.2 TCP并不能保证数据传输可靠

上述说的TCP保证可靠的机制全部是基于端到端通信的可靠。如果数据是在一个用户内的进程间传输,即没有访问到TCP,此时数据并没有走TCP,直接在IP层就进行转发了,那么IP协议可是不保证数据传输的可靠性的。

在这里插入图片描述

另外,TCP已经ACK的数据包实际上不一定会抵达应用进程。就算TCP所有到达目标进程的数据是完整的,接收端TCP对数据进行ACK后,应用程序还没有读走就发送了奔溃,就会导致传输不可靠。这里给出的解决方案是在应用层增加一个ACK机制,具体实现得在之后的学习中深耕。


8.TCP和UDP区别

两者都是传输层的协议,下面先介绍以下UDP

在IP协议基础上增加多路复用、分用和差错检测功能。报文段:

在这里插入图片描述

UDP提供了差错检验功能,详看:https://blog.csdn.net/yeahPeng11/article/details/117486184

TCP:面向连接,一对一传输,传输可靠,以字节流形式传输,传输效率低,所需资源多,首部字节20-60个。有确认、窗口 、重传、拥塞控制机制。常用协议:FTP(21和20端口),SMTP(25端口),HTTP(80端口)。

UDP:面向无连接,一对多传输,传输不可靠,以数据报文段传输,效率高,所需资源少,首部字节8个。常用协议:DNS(53端口),TFTP(69端口)


9.TCP的滑动窗口和流量控制

所谓流量控制:让发送方的发送速率不要太快,要接收方来得及接收

采用滑动窗口机制,接收方根据自己的TCP接收的接收缓存,动态的调整发送方发送窗口的大小。接收窗口rwnd(reception window)和发送窗口cwndcongestion window)的最小值。

TCP的窗口单位是字节,不是报文段


10.TCP拥塞控制

拥塞就是对资源的需求大于可用资源。即接收方接受不了,用窗口尺寸度量;通信子网出现拥塞(很难获取)。

拥塞控制是对全局性的过程,流量控制的值对点到点的控制。

拥塞控制就是防止过多的数据注入到网络中,拥塞控制方法主要有:慢开始和拥塞避免传重传和快恢复

这四种机制都不能完全避免拥塞,只是使网络比较不容易出现拥塞

慢开始&拥塞避免

RTT:一个往返时间

起始时设置拥塞窗口cwnd=1,然后每经过一个RTT传输轮次,拥塞窗口大小*2,直到拥塞窗口大小为ssthresh(Slow Start Threshold)慢开始门限值,即进入拥塞避免阶段,拥塞窗口随RTT线性增长每次+1,直到到达网络拥塞状态,将拥塞窗口大小重置为1,慢开始门限ssthresh置为网络拥塞窗口的一半。以此往复。网络拥塞的判断依据是没有按时收到确认。

在这里插入图片描述


快重传和快恢复

和慢开始&拥塞避免算法的区别就是在到达网络拥塞后不再指向慢开始算法,而是执行加法增大算法,即把cwnd置为新的ssthresh,开始+1线性操作。那么判断它到达网络拥塞的条件就是发送方接收到三个重复确认

在这里插入图片描述


11.客户端不断进行请求链接会怎么样?DDOS(Distributed Denial of Service)攻击?

服务器会为每个请求创建一个连接,并向其发送确认报文,然后等待客户端进行确认

DDOS攻击

  1. 客户端向服务器端发送请求连接数据包;
  2. 服务器端向客户端发送确认数据包;
  3. 客户端消失,服务器端一直等待客户端的确认消息。

DDOS预防

没有彻底根治的方法,除非不使用TCP,0.0

  1. 限制同时打开SYN半连接的数目;
  2. 缩短SYN半连接的Time out时间;
  3. 关闭不必要的服务。

12.FTP是什么协议

TFTP,Trivial File Transfer Protocol,普通文件传输协议,面向无连接的、不可靠的服务,采用UDP在支持TFTP的系统间传输文件。69端口

FTP,File Transfer Protocol,文件传输协议,是TCP/IP协议中的协议之一,21和20端口。是一种可靠的面向连接的、可靠的服务。使用两根TCP连接,21端口是控制连接,20端口传输数据

采用双TCP的优点是:简单,提供终止传输,断点续传等。但是也不总是使用20端口建立数据连接,被动时就和客户端自行协商决定大于1024的端口

在这里插入图片描述

在这里插入图片描述


13.HTTP协议

Hyper Text Transfer Protocol,超文本传输协议。超文本指的是HTML,CSS,JavaScript和图片等。HTTP协议是使用TCP作为其传输层协议的,当TCP出现瓶颈时,HTTP也会受到影响。

HTTP的请求报文和响应报文由三部分组成:请求行/状态行首部行实体主体

请求行:请求方式+请求URI+协议及其版本

状态行:协议及其版本+状态码+原因短语

在这里插入图片描述

HTTP是无状态协议,传输完数据后就断开TCP连接,之后再发送需再次建立TCP连接。HTTP1.1引入Cookie实现持久化,可实现用户状态管理,不立马断开TCP连接。

HTTP采用TCP作为传输层协议,但是HTTP协议本身是无连接的。

HTTP请求常见的几种类型:

HTTP请求描述
GET为获取资源数据
HEAD为读取资源的元数据
POST为提交资源数据
PUT为更新资源数据
DELETE为删除资源数据
CONNECT为保留将来使用
OPTIONS为读取资源多支持的所有请求方法
TRACE显示服务器额外请求

13.URI,URL,URN区别

URI:Uniform Resource Identifier,统一资源标识符.

URL:Uniform Resource Locator,统一资源定位符.

URN:Uniform Resource Name,统一资源名称.

URL和URN都是URI的子集。

在这里插入图片描述

URL:是URI的一种,不仅标识了Web资源,还指定了操作或者获取方式,同时指出了主要访问机制和网络位置。格式

URN:是URI的一种,用特别命名空间的名字标识资源。使用URN可以在不知道网络位置及访问方式的情况下讨论资源。

下面看一个栗子:有一个URI是http://bitpoetry.io/posts/hello.html#intro

http://是定义如何访问资源的方式,另外bitpoetry.io/posts/hello.html是资源存放位置,#intro是资源。

其中URL:http://bitoetry.io/posts/hello.html

其中URN:bitpoetry.io/posts/hello.html#intro


14.GET和POST的区别

GET和POST是我们常用的两种HTTP Method,二者之间的区别主要包括如下五个方面

  1. 功能上讲,GET一般用来从服务器上获取资源,POST一般用来更新服务器上的资源

  2. REST服务角度上说,GET是幂等的,即读取同一个资源,总是得到相同的数据,而POST不是幂等的,因为每次请求对资源的改变并不是相同的;进一步地,GET不会改变服务器上的资源,而POST会对服务器资源进行改变;

    RESTful风格补习一下

  3. 请求参数形式上看,GET请求的数据会附在URL之后,即将请求数据放置在HTTP报文的 请求头 中,以?分割URL和传输数据,参数之间以&相连。特别地,如果数据是英文字母/数字,原样发送;否则,会将其编码为 application/x-www-form-urlencoded MIME字符串(如果是空格,转换为+,如果是中文/其他字符,则直接把字符串用BASE64加密,得出如:%E4%BD%A0%E5%A5%BD,其中%XX中的XX为该符号以16进制表示的ASCII);而POST请求会把提交的数据则放置在是HTTP请求报文的请求体中。

  4. 安全性而言,POST的安全性要比GET的安全性高,因为GET请求提交的数据将明文出现在URL上,而且POST请求参数则被包装到请求体中,相对更安全。

  5. 请求的大小看,GET请求的长度受限于浏览器或服务器对URL长度的限制,允许发送的数据量比较小,而POST请求则是没有大小限制的。


15.HTTP和HTTPS的区别

HTTP运行在TCP之上,明文传输,客户端与服务器端都无法验证对方身份;HTTPS是运行于SSL(Secure Socket Layer,安全套接层)上,SSL运行于TCP上,是添加了加密和认证机制的HTTP。二者之间存在如下不同:

  1. 端口不同:HTTP80端口,HTTPS433端口;
  2. 资源消耗:和HTTP通信相比,HTTPS通信会由于加密处理消耗更多的CPU和内存资源;
  3. 开销:HTTPS通信需要证书,证书需要向认证机构购买;

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


16.对称加密和非对称加密

对称加密指的是加密和解密使用同一个密匙的方式,这种方式最大的问题就是如何安全把密匙发送给对方;而非对称加密指的是使用一对非对称的密匙,即公钥和私钥,公钥随意发布,私钥只有自己有。发送密文的一方使用对方的公钥进行加密处理,对方接收到消息后使用自己的私钥解析解密。

但是由于非对称加密的方式发送数据非常慢,一般就使用对称加密方式来传送数据,使用非对称加密方式来传递对称加密使用的密匙


17.浏览器输入网址回车经历的过程

这个对于用户来说就是在浏览器页面输入网址或点击网址以后,用户就能获取到信息,那么从计算机网络的角度来的过程是怎么样的?

先看一下简单的网络模型

在这里插入图片描述

1.DNS域名解析

浏览器做的第一步其实是对URL进行解析,从而生成发送给Web服务器的请求信息。

输入一个域名回车后,浏览器搜索自身的DNS缓存、搜索操作系统的DNS缓存、读取本地的Host文件和向本地DNS服务器进行查询等。(计算机用户可以直接对hosts文件进行控制)。直到找到此域名返回IP。

2.建立TCP连接

获取IP后,浏览器向服务器发起TCP三次握手建立连接。

3.HTTP请求响应

建立好TCP连接后,浏览器通过http协议发送请求,请求数据包;之后服务器根据路径参数映射到特定的请求处理器进行处理,并将请求的数据返回给浏览器。

4.释放TCP连接

浏览器与服务器数据传送完毕后,释放TCP连接,四次握手。

5.浏览器显示

浏览器解析并且渲染视图,若遇到js、css文件及图片等静态资源的引用,重复上述步骤并向服务器请求这些资源。之后浏览器对数据进行解析并渲染显示。


18.HTTP1.0,1.1,2.0,3.0的区别

HTTP/1.0的主要缺点

每个TCP连接只能发送一个请求,发送完毕就关闭连接,新的传输需要新的TCP连接。HTTP不保存状态,无状态协议,不能做持久化处理,

HTTP1.1虽然是无状态协议,但是实现了状态管理功能,引入Cookie,TCP连接默认不关闭,一段时间后关闭

19.HTTP常见状态码

状态码的职责是当客户端向服务器端发送请求时,描述返回的请求结果。借助状态码,用户可以知道服务器端是正常处理了请求,还是出现了错误。

  • 1xx:表示通知消息的,如请求处理收到了或正在进行处理。
  • 2xx:表示成功,如接受或知道了。200 OK
  • 3xx:表示重定向,如要完成请求还必须采取进一步的行动。
    • 301:永久性转移
    • 302:暂时性转移
    • 304:已缓存
  • 4xx:表示客户端的差错,如请求中有错误的语法不能完成
    • 400:请求有语法错误
    • 403:拒绝请求
    • 404:客户端所访问的页面不存在
  • 5xx:表示服务器的差错,如服务器失效无法完成请求
    • 500:服务器内部错误
    • 503:服务器不可用,稍等

20.TCP粘包是怎么产生的

前提条件:TCP保存长连接(使用HTTP1.1协议)。就是发送一次数据后不断开连接,双方不断开连接的情况下,可以一直传输数据。

发送方产生粘包

发送的数据包过于小时,TCP协议默认启用Nagle算法,将这些较小的数据包合并发送(TCP缓冲区数据发送是一个堆压的过程),这个合并过程就是在发送缓冲区进行的,即数据发送出来已经是处于粘包状态了。

在这里插入图片描述

接收方产生粘包

产生粘包的条件是:TCP的缓冲区存储的数据不能及时被程序中读取数据的函数及时取出,而下一个数据数据又接收到,并有一部分放入缓冲区末尾,此时TCP缓存中等待读取的数据就是一个粘包。(放数据的速度>应用层读取数据的速度)。

在这里插入图片描述


21.网络层的IP协议

IP,Internet Protocol,互联网协议。IP协议所定义的地址是IP地址,IP协议分为IPv4IPv6,这里仅仅讨论IPv4。

IP由32位(4字节)二进制位组成,一般表示为4段十进制(0.0.0.0~255.255.255.255),IP地址分为网络部分和主机部分,两部分所占的二进制数不固定。由子网掩码来判断不同的IP是否在同一个子网中。把IP地址与它的子网掩码做 与(&) 运算,得到的结果相同就代表在同一个子网,否则不在同一个子网。

子网掩码也是32位二进制数,它的网络部分全部为1,主机部分全部为0。例如192.169.119.1/192.169.119.2的子网掩码都是255.255.255.0,与运算后得到192.169.119.0,处于同一个子网中。

在这里插入图片描述


22.网络层的ARP协议

ARP请求数据包中包括:源机IPMAC硬件地址、以及目的主机的IP地址

ARP,Address Resolution Protocol,地址解析协议。网络层的APR协议完成了IP地址与物理地址的映射。每个主机都会在自己的APR缓冲区中建立一个APR列表,以表示IP地址和MAC地址的对应关系。

当源主机需要发送数据包到目的主机时,首先检查自己ARP列表中是否含有该IP地址对应的MAC地址,如果有,直接发送次数据包到这个MAC地址;如果没有,就在同一个子网中通过广播的形式发起一个ARP请求包,查询此目的机对应的MAC地址。

网络中所有收到这个ARP请求的主机,会检查数据包中的目的机IP是否与自己的IP地址一致,不相同就忽略此数据包;如果相同,该主机首先将发送端的IP地址和MAC地址添加到自己的ARP列表中(或覆盖),然后给源机发送一个ARP响应数据包。

源机收到这个ARP响应数据包后,将得到的目的机IP地址和MAC地址添加到自己的ARP列表中,并利用此消息开始数据传输。

若源机一直没有收到ARP响应数据包,表示ARP查询失败。

标签:Inversion,Java,请求,TCP,发送,Interview,数据,连接,客户端
来源: https://blog.csdn.net/yeahPeng11/article/details/118607425

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有