计算机网络面试

(1)说一下三次握手，为什么三次握手?

原因1：相互确认

Step1       A -> B : 你好，B。

Step2       A <- B : 收到。你好，A。

Step3       A -> B : 收到，B。

原因2：防止重复连接

第一次握手：SYN报文段(即SYN=1的报文段)不能携带数据，但要消耗掉一个序号。

第二次握手：这个ACK报文段也不能携带数据，但同样要消耗掉一个序号。

第三次握手：ACK报文段可以携带数据，但如果不携带数据则不消耗序号。

在TCP的socket编程中，发送端和接收端都有成对的socket。发送端为了将多个发往接收端的包，更加高效的的发给接收端，于是采用了优化算法（Nagle算法），将多次间隔较小、数据量较小的数据，合并成一个数据量大的数据块，然后进行封包。那么这样一来，接收端就必须使用高效科学的拆包机制来分辨这些数据。

只有上一个分组得到确认，才会发送下一个分组

收集多个小分组，在一个确认到来时一起发送

3.Q：什么时候需要处理粘包现象？

方法1：对于发送方引起的粘包现象，用户可通过编程设置来避免，TCP提供了强制数据立即传送的操作指令push，TCP软件收到该操作指令后，就立即将本段数据发送出去，而不必等待发送缓冲区满。

方法2：对于接收方引起的粘包，则可通过优化程序设计、精简接收进程工作量、提高接收进程优先级等措施，使其及时接收数据，从而尽量避免出现粘包现象。

方法3：由接收方控制，将一包数据按结构字段，人为控制分多次接收，然后合并，通过这种手段来避免粘包。

以上提到的三种措施，都有其不足之处:

第一种编程设置方法虽然可以避免发送方引起的粘包，但它关闭了优化算法，降低了网络发送效率，影响应用程序的性能，一般不建议使用。

第二种方法只能减少出现粘包的可能性，但并不能完全避免粘包，当发送频率较高时，或由于网络突发可能使某个时间段数据包到达接收方较快，接收方还是有可能来不及接收，从而导致粘包。

第三种方法虽然避免了粘包，但应用程序的效率较低，对实时应用的场合不适合。

方法1：格式化数据：每条数据有固定的格式（开始符，结束符），这种方法简单易行，但是选择开始符和结束符时一定要确保每条数据的内部不包含开始符和结束符。

方法2：发送长度：发送每条数据时，将数据的长度一并发送，例如规定数据的前4位是数据的长度，应用层在处理时可以根据长度来判断每个分组的开始和结束位置。(更推荐)

UDP不存在粘包问题，是由于UDP发送的时候，没有经过Negal算法优化，不会将多个小包合并因此发送出去。另外，在UDP协议的接收端，采用了链式结构来记录每一个达到UDP包，这样接收端应用程序一次recv只能从socket接收缓冲区中读出一个数据包。也就是说，发送端send了几次，接收端必须recv几次（无论recv时执行了多大的缓冲区）。

面向报文是指应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文。因此，应用程序必须选择合适大小的报文。若报文太长，则IP层需要分片，降低效率。若太短，会是IP太小。UDP对应用层交下来的报文，即不合并，也不拆分，而是保留这些报文的边界。这就是说，应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文。

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

(3)TCP怎么做到数据传输不出差错的?

(1)校验和

计算方式：在数据传输的过程中，将发送的数据段分成一个个16比特字。将这些16比特字加起来。并且前面的进位不能丢弃，补在后面(回卷)，最后取反，得到校验和。

发送方：在发送数据之前计算检验和，并进行校验和的填充。

接收方：收到数据后，对数据以同样的方式对数据段分成的比特字进行相加回卷计算(不用取反)，将计算结果和发送方的校验和相加，如果没有出现差错那么最后的结果应该是全1，否则表示报文段出现差错。

序列号：TCP传输时将每个字节的数据都进行了编号，这就是序列号。

确认应答：TCP传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答。也就是发送ACK报文。这个ACK报文当中带有对应的确认序列号ack，接收方期望发送方发送的下一个报文段的第一个数据字节的序号(隐含表示对在这之前的所有数据(<=ack-1)的确认接收)。

1.数据在传输过程中由于网络原因等直接全体丢包，接收方根本没有接收到。

2.接收方接收到了响应的数据，但是发送的ACK报文响应却由于网络原因丢包了。

由于TCP传输时需要保证能够在任何环境下都有一个高性能的通信，因此这个最大超时时间（也就是等待的时间）是动态计算的。

karn算法根据旧的RTT1和新的RTT2得到加权平均往返时间RTTs，再计算出RTT的偏差的加权平均值RTTd。最后得到超时重传时间RTO=RTTs+4*RTTd，而且当报文段每重传一次就把RTO增大一些，典型做法是  

               取新的RTT为旧的RTT的2倍。

例：在Linux中（BSD Unix和Windows下也是这样）超时以500ms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍。重发一次后，仍未响应，那么等待2*500ms的时间后，再次重传。等待4*500ms的时间继续重传。以一个指数的形式增长。累计到一定的重传次数，TCP就认为网络或者对端出现异常，强制关闭连接。

TCP三次握手：

第一次握手：建立连接时，客户端发送syn包（syn=x）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。

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

第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=y+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。

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

2）服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。

3）客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。

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

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

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

(1)慢启动：开始开始发送方拥塞窗口cwnd=1，之后每发发送一条报文段且收到ACK后将cwnd+1,所以慢开始每一轮发送增长一倍，cwnd呈指数型快速增长，直到重传或者到达门限ssthresh。

(2)拥塞控制：每经过一个传输轮次，拥塞窗口cwnd=cwnd+1,使拥塞窗口cwnd按线性规律缓慢增长，直到出现重传。

(3)快重传：要求接收方不要等待自己发送数据时才捎带确认，而是要立刻发送确认，即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认，发送方一旦收到3个连续的重复确认，就将相应的报文段立即重传，而不是等待该报文段的超时计时器超时再重传（快重传之后配合快恢复，对于个别丢失的报文段，发送方不会出现超时重传，也就不会误认为出现了拥塞而将cwnd降低为1，而是将ssthresh=cwnd/2且设置新的cwnd=ssthresh并线性增长，使用快重传可以整个网络吞吐量提高约20%）

(4)快恢复：发送方调整门限值ssthresh=cwnd/2,同时设置拥塞窗口cwnd=ssthresh，并开始执行拥塞避免算法。

TCP传输的过程中，发送端开始发送数据的时候，如果刚开始就发送大量的数据，那么就可能造成一些问题。网络可能在开始的时候就很拥堵，如果给网络中在扔出大量数据，那么这个拥堵就会加剧。拥堵的加剧就会产生大量的丢包，就对大量的超时重传，严重影响传输。
所以TCP引入了慢启动的机制，在开始发送数据时，先发送少量的数据探路。探清当前的网络状态如何，再决定多大的速度进行传输。这时候就引入一个叫做拥塞窗口的概念。发送刚开始定义拥塞窗口为 1，每次收到ACK应答，拥塞窗口加 1。在发送数据之前，首先将拥塞窗口与接收端反馈的窗口大小比对，取较小的值作为实际发送的窗口。
拥塞窗口的增长是指数级别的。慢启动的机制只是说明在开始的时候发送的少，发送的慢，但是增长的速度是非常快的。为了控制拥塞窗口的增长，不能使拥塞窗口单纯的加倍，设置一个拥塞窗口的阈值，当拥塞窗口大小超过阈值时，不能再按照指数来增长，而是线性的增长。在慢启动开始的时候，慢启动的阈值等于窗口的最大值，一旦造成网络拥塞，发生超时重传时，慢启动的阈值会为原来的一半（这里的原来指的是发生网络拥塞时拥塞窗口的大小），同时拥塞窗口重置为 1。


拥塞控制是TCP在传输时尽可能快的将数据传输，并且避免拥塞造成的一系列问题。是可靠性的保证，同时也是维护了传输的高效性。

因为局域网内是通过 MAC 进行识别的，为什么要用 MAC 地址识别呢？是这样的，以前没这么多主机的时候，IP 是固定的，我们就不需要 MAC，但现在主机越来越多，这就导致局域网里 IP 不是十分充足，管理起来也不是很好管理，所以 IP 每隔一段时间就会被回收，需要的时候才会被分配，这也就是为什么前面提到的 DHCP 动态主机配置协议会存在，所以这个 IP 是会变的，对于主机来说，唯一不变的是 MAC，所以，在局域网内部我们是用 MAC 定位的。

TCP 提供的是面向连接，可靠的面向字节流服务。即客户和服务器交换数据前，必须现在双方之间建立一个TCP连接，之后才能传输数据。并且提供超时重发，检验数据，流量控制等功能，保证数据能从一端传到另一端不重复不丢失不失序。

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

TCP套接字编程

TCP编程的服务器端一般步骤是：

1. 创建一个socket，用函数socket()；
2. 设置socket属性，用函数setsockopt(); * 可选
3. 绑定IP地址、端口等信息到socket上，用函数bind();
4. 开启监听，用函数listen()；
5. 接收客户端上来的连接，用函数accept()；
6. 收发数据，用函数send()和recv()，或者read()和write();
7. 关闭网络连接；
8. 关闭监听；

TCP编程的客户端一般步骤是：

1. 创建一个socket，用函数socket()；
2. 设置socket属性，用函数setsockopt(); * 可选
3. 绑定IP地址、端口等信息到socket上，用函数bind(); * 可选
4. 设置要连接的对方的IP地址和端口等属性；
5. 连接服务器，用函数connect()；
6. 收发数据，用函数send()和recv()，或者read()和write();
7. 关闭网络连接；

UDP套接字编程

UDP编程的服务器端一般步骤是：

1. 创建一个socket，用函数socket()；
2. 设置socket属性，用函数setsockopt();* 可选
3. 绑定IP地址、端口等信息到socket上，用函数bind();
4. 循环接收数据，用函数recvfrom();
5. 关闭网络连接；

UDP编程的客户端一般步骤是：

1. 创建一个socket，用函数socket()；
2. 设置socket属性，用函数setsockopt();* 可选
3. 绑定IP地址、端口等信息到socket上，用函数bind();* 可选
4. 设置对方的IP地址和端口等属性;
5. 发送数据，用函数sendto();
6. 关闭网络连接；

(6)UDP和TCP的编写过程?

(7)说一下网络的拥塞控制?

(9)说一下Dijkstra算法？