常见面试题（总结）- 网络基础

常见面试题（总结）- 网络基础

1.TCP和UDP的区别与其适用场景？

TCP协议头：

UDP协议头：

IP协议：

区别：

1.面向连接VS无连接

• TCP是面向连接的协议，也就是说，在收发数据前，必须和对方建立可靠的连接。一个TCP连接必须要经过三次“对话”才能建立。
• UDP是一个非连接的协议，传输数据之前源端和终端不建立连接，当它想传送时就简单地去抓取来自应用程序的数据，并尽可能快地把它扔到网络上。

2.可靠VS不可靠

• TCP利用三次握手、ACK（收到的每一个包，都会返回一个ACK确认包）和重传机制，UDP没有。

3.面向字节流vs面向报文

• udp面向报文：

面向报文的传输方式是应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文。因此，应用程序必须选择合适大小的报文。若报文太长，则IP层需要分片。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。这也就是说，应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文。（一个upd的最大报文长度2^16-1-20-8, 20是ip报文头，8是udp报文头）

• tcp面向字节流

面向字节流的话，虽然应用程序和TCP的交互是一次一个数据块（大小不等），但TCP把应用程序看成是一连串的无结构的字节流。TCP有一个缓冲，当应用程序传送的数据块太长，TCP就可以把它划分短一些再传送。如果应用程序一次只发送一个字节，TCP也可以等待积累有足够多的字节后再构成报文段发送出去。

TCP应用场景：

效率要求相对低，但对准确性要求相对高的场景。因为传输中需要对数据确认、重发、排序等操作，相比之下效率没有UDP高。举几个例子：文件传输（准确高要求高、但是速度可以相对慢）、接受邮件、远程登录。

UDP应用场景：

效率要求相对高，对准确性要求相对低的场景。举几个例子：在线视频、网络语音电话（即时通讯，速度要求高，但是出现偶尔断续不是太大问题，并且此处完全不可以使用重发机制）

2.什么是三次握手和四次握手？

参考链接

三次握手过程理解：

1. 第一次握手：建立连接时，客户端发送SYN包（seq=x）到服务器，并进入SYN_SENT状态，等待服务器确认；（seq为序列号，用来标记数据段的顺序，后续的包的seq依次+1，SYN为同步序列编号，为TCP头部的其中一位，建立连接时，设置为1。）
2. 第二次握手：服务器收到SYN包，必须确认客户的SYN，也要发起和对方建立连接的请求。于是也发送一个SYN+ACK包，将其确认号ack置为x+1表示确认收到（seq=y，ack=x+1, SYN=1），此时服务器进入SYN_RECV状态；（ack为确认号，当正确收到seq=x的包时，返回一个ack=x+1的包，表示确认收到）
3. 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=y+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。

四次握手过程理解：

1. 第一次握手：客户端进程发出连接释放FIN包，并且停止发送数据。(FIN=1，其序列号为seq=u)，此时，客户端进入FIN-WAIT-1（终止等待1）状态。

2. 第二次握手：服务器收到连接释放报文，发出确认ACK包，（ACK=1，ack=u+1，seq=v），此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。
   TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受，这个状态还要持续一段时间。
   客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的应答数据）

3. 第三次握手：服务器将最后的数据发送和接受完毕后，就向客户端发送连接释放FIN包，（FIN=1，ack=u+1），由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。

4. 第四次握手：客户端收到服务器的连接释放报文后，必须发出确认ACK包，（ACK=1，ack=w+1），而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
   服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些

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

因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

为什么不能用两次握手进行连接？

3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。
现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

3.http和https的区别？

参考链接
百度百科-http
百度百科-https

http：

HTTP是基于客户/服务器模式，且面向连接的。典型的HTTP事务处理有如下的过程：

• （1）客户与服务器建立连接；
• （2）客户向服务器提出请求；
• （3）服务器接受请求，并根据请求返回相应的文件作为应答；
• （4）客户与服务器关闭连接。

客户与服务器之间的HTTP连接是一种一次性连接，它限制每次连接只处理一个请求，当服务器返回本次请求的应答后便立即关闭连接，下次请求再重新建立连接。这种一次性连接主要考虑到WWW服务器面向的是Internet中成干上万个用户，且只能提供有限个连接，故服务器不会让一个连接处于等待状态，及时地释放连接可以大大提高服务器的执行效率。

https：

HTTPS是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。用于安全的HTTP数据传输。

https主要作用可以分为两种：

• 一是建立一个信息安全通道，来保证数据传输的安全；
• 二是确认网站的真实性，凡是使用了 https 的网站，都可以通过点击浏览器地址栏的锁头标志来查看网站认证之后的真实信息，也可以通过 CA机构颁发的安全签章来查询 。

http通信的步骤：

4.TCP通信之前服务器和客户端一般都做了些什么？

参考链接

具体的API使用查看以上链接（面试常问通信API的参数）

5.http状态码

参考链接

1开头表示客户端应该继续发送请求

2开头表示成功的请求

200表示OK，正常返回信息
201表示请求成功且服务器创建了新的资源
202表示服务器已经接受了请求，但还未处理

3开头表示重定向

301表示永久重定向，请求的网页已经永久移动到新位置
302表示临时重定向
304表示自从上一次请求以来，页面的内容没有改变过

4开头表示客户端错误

401表示服务器无法理解请求的格式
402表示请求未授权
403表示禁止访问
404表示请求的资源不存在，一般是路径写错了

5开头表示服务器错误
500表示最常见的服务器错误
503表示服务器暂时无法处理请求

6.什么是cookie？什么是session？session和cookie有什么区别？

Cookie

Cookie是客户端保存用户信息的一种机制，用来记录用户的一些信息。如何识别特定的客户呢？cookie就可以做到。每次HTTP请求时，客户端都会发送相应的Cookie信息到服务端。它的过期时间可以任意设置，如果你不主动清除它，在很长一段时间里面都可以保留着，即便这之间你把电脑关机了。
Cookie还可以在一些方便用户的场景下使用。比如你某次登陆过一个网站，下次登录的时候不想再次输入账号了，怎么办？这个信息可以被写到Cookie里面，当访问网站时，网站页面的脚本可以读取这个信息，自动填写用户名，方便用户使用，给用户一点甜头。
既然它是存储在客户端的，换句话说通过某些手法我就可以篡改本地存储的信息来欺骗服务端的某些策略，所以就用到了—— Session。

Session

Session是在无状态的HTTP协议下，服务端记录用户状态时用于标识具体用户的机制。它是在服务端保存的用来跟踪用户的状态的数据结构，可以保存在文件、数据库或者集群中。在浏览器关闭后这次的Session就消失了，下次打开就不再拥有这个Session。其实并不是Session消失了，而是Session ID变了，服务器端可能还是存着你上次的Session ID及其Session 信息，只是他们是无主状态。
目前大多数的应用都是用 Cookie 实现Session跟踪的。第一次创建Session时，服务端会通过在HTTP协议中反馈到客户端，需要在 Cookie 中记录一个Session ID，以便今后每次请求时都可分辨你是谁。有人问，如果客户端的浏览器禁用了 Cookie 怎么办？建议使用URL重写技术进行会话跟踪，即每次HTTP交互，URL后面都被附加上诸如 sid=xxxxx 的参数，以便服务端依此识别用户
用户验证这种场合一般会用 Session。因此，维持一个会话的核心就是客户端的唯一标识，即Session ID。