后台开发面试-计算机网络(一)

1、三次握手

（1）三次握手的详述

首先Client端发送连接请求报文，Server段接受连接后回复ACK报文，并为这次连接分配资源。Client端接收到ACK报文后也向Server段发生ACK报文，并分配资源，这样TCP连接就建立了。

最初两端的TCP进程都处于CLOSED关闭状态，A主动打开连接，而B被动打开连接。（A、B关闭状态CLOSED——B收听状态LISTEN——A同步已发送状态SYN-SENT——B同步收到状态SYN-RCVD——A、B连接已建立状态ESTABLISHED）

B的TCP服务器进程先创建传输控制块TCB，准备接受客户进程的连接请求。然后服务器进程就处于LISTEN（收听）状态，等待客户的连接请求。若有，则作出响应。
1）第一次握手：A的TCP客户进程也是首先创建传输控制块TCB，然后向B发出连接请求报文段，（首部的同步位SYN=1，初始序号seq=x），（SYN=1的报文段不能携带数据）但要消耗掉一个序号，此时TCP客户进程进入SYN-SENT（同步已发送）状态。
2）第二次握手：B收到连接请求报文段后，如同意建立连接，则向A发送确认，在确认报文段中（SYN=1，ACK=1，确认号ack=x+1，初始序号seq=y），测试TCP服务器进程进入SYN-RCVD（同步收到）状态；
3）第三次握手：TCP客户进程收到B的确认后，要向B给出确认报文段（ACK=1，确认号ack=y+1，序号seq=x+1）（初始为seq=x，第二个报文段所以要+1），ACK报文段可以携带数据，不携带数据则不消耗序号。TCP连接已经建立，A进入ESTABLISHED（已建立连接）。
当B收到A的确认后，也进入ESTABLISHED状态。

（2）总结三次握手过程：

第一次握手：起初两端都处于CLOSED关闭状态，Client将标志位SYN置为1，随机产生一个值seq=x，并将该数据包发送给Server，Client进入SYN-SENT状态，等待Server确认；
第二次握手：Server收到数据包后由标志位SYN=1得知Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=x+1，随机产生一个值seq=y，并将该数据包发送给Client以确认连接请求，Server进入SYN-RCVD状态，此时操作系统为该TCP连接分配TCP缓存和变量；
第三次握手：Client收到确认后，检查ack是否为x+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=y+1，并且此时操作系统为该TCP连接分配TCP缓存和变量，并将该数据包发送给Server，Server检查ack是否为y+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client和Server就可以开始传输数据。

起初A和B都处于CLOSED状态——B创建TCB，处于LISTEN状态，等待A请求——A创建TCB，发送连接请求（SYN=1，seq=x），进入SYN-SENT状态——B收到连接请求，向A发送确认（SYN=ACK=1，确认号ack=x+1，初始序号seq=y），进入SYN-RCVD状态——A收到B的确认后，给B发出确认（ACK=1，ack=y+1，seq=x+1），A进入ESTABLISHED状态——B收到A的确认后，进入ESTABLISHED状态。

TCB传输控制块Transmission Control Block，存储每一个连接中的重要信息，如TCP连接表，到发送和接收缓存的指针，到重传队列的指针，当前的发送和接收序号。

（3）为什么A还要发送一次确认呢？可以二次握手吗？

　　答：主要为了防止已失效的连接请求报文段突然又传送到了B，因而产生错误。如A发出连接请求，但因连接请求报文丢失而未收到确认，于是A再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，A 工发出了两个连接请求报文段，其中第一个丢失，第二个到达了B，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达B，此时B误认为A又发出一次新的连接请求，于是就向A发出确认报文段，同意建立连接，不采用三次握手，只要B发出确认，就建立新的连接了，此时A不理睬B的确认且不发送数据，则B一致等待A发送数据，浪费资源。

（4）Server端易受到SYN攻击？

服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN洪泛攻击，SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。

防范SYN攻击措施：降低主机的等待时间使主机尽快的释放半连接的占用，短时间受到某IP的重复SYN则丢弃后续请求。

2、四次挥手

（1）四次挥手的详述

　　假设Client端发起中断连接请求，也就是发送FIN报文。Server端接到FIN报文后，意思是说"我Client端没有数据要发给你了"，但是如果你还有数据没有发送完成，则不必急着关闭Socket，可以继续发送数据。所以你先发送ACK，"告诉Client端，你的请求我收到了，但是我还没准备好，请继续你等我的消息"。这个时候Client端就进入FIN_WAIT状态，继续等待Server端的FIN报文。当Server端确定数据已发送完成，则向Client端发送FIN报文，"告诉Client端，好了，我这边数据发完了，准备好关闭连接了"。Client端收到FIN报文后，"就知道可以关闭连接了，但是他还是不相信网络，怕Server端不知道要关闭，所以发送ACK后进入TIME_WAIT状态，如果Server端没有收到ACK则可以重传。“，Server端收到ACK后，"就知道可以断开连接了"。Client端等待了2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，我Client端也可以关闭连接了。Ok，TCP连接就这样关闭了！

数据传输结束后，通信的双方都可释放连接，A和B都处于ESTABLISHED状态。（A、B连接建立状态ESTABLISHED——A终止等待1状态FIN-WAIT-1——B关闭等待状态CLOSE-WAIT——A终止等待2状态FIN-WAIT-2——B最后确认状态LAST-ACK——A时间等待状态TIME-WAIT——B、A关闭状态CLOSED）

1）A的应用进程先向其TCP发出连接释放报文段（FIN=1，序号seq=u），并停止再发送数据，主动关闭TCP连接，进入FIN-WAIT-1（终止等待1）状态，等待B的确认。
2）B收到连接释放报文段后即发出确认报文段，（ACK=1，确认号ack=u+1，序号seq=v），B进入CLOSE-WAIT（关闭等待）状态，此时的TCP处于半关闭状态，A到B的连接释放。
3）A收到B的确认后，进入FIN-WAIT-2（终止等待2）状态，等待B发出的连接释放报文段。
4）B没有要向A发出的数据，B发出连接释放报文段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），B进入LAST-ACK（最后确认）状态，等待A的确认。
5）A收到B的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），A进入TIME-WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，A才进入CLOSED状态。

（2）总结四次挥手过程：

起初A和B处于ESTABLISHED状态——A发出连接释放报文段并处于FIN-WAIT-1状态——B发出确认报文段且进入CLOSE-WAIT状态——A收到确认后，进入FIN-WAIT-2状态，等待B的连接释放报文段——B没有要向A发出的数据，B发出连接释放报文段且进入LAST-ACK状态——A发出确认报文段且进入TIME-WAIT状态——B收到确认报文段后进入CLOSED状态——A经过等待计时器时间2MSL后，进入CLOSED状态。

（3）为什么A在TIME-WAIT状态必须等待2MSL的时间？

MSL最长报文段寿命Maximum Segment Lifetime，MSL=2

答：　　两个理由：

1）保证A发送的最后一个ACK报文段能够到达B。2）防止“已失效的连接请求报文段”出现在本连接中。

1）这个ACK报文段有可能丢失，使得处于LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认，B超时重传FIN+ACK报文段，而A能在2MSL时间内收到这个重传的FIN+ACK报文段，接着A重传一次确认，重新启动2MSL计时器，最后A和B都进入到CLOSED状态，若A在TIME-WAIT状态不等待一段时间，而是发送完ACK报文段后立即释放连接，则无法收到B重传的FIN+ACK报文段，所以不会再发送一次确认报文段，则B无法正常进入到CLOSED状态。
2）A在发送完最后一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文段。

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

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

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

答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。

半打开，半关闭，半连接

一、半连接

1.1 定义

      发生在TCP3次握手中。
      如果A向B发起TCP请求，B也按照正常情况进行响应了，但是A不进行第3次握手，这就是半连接。
1.2 半连接攻击

     半连接，会造成B分配的内存资源就一直这么耗着，直到资源耗尽。

二、半打开（Half-Open）

2.1 定义

      如果一方已经关闭或异常终止连接，而另一方却不知道。我们将这样的TCP连接称为半打开（Half-Open）。

三、半关闭

3.1 定义

      TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力，这就是TCP的半关闭。
      当一方关闭发送通道后，仍可接受另一方发送过来的数据，这样的情况叫“半关闭”。（拆除TCP连接是：你关闭你的发送通道，我关闭我的发送通道）。
3.2 半关闭的产生

      1. 客户端发送FIN，另一端发送对这个FIN的ACK报文段。此时客户端就处于半关闭。
      2. 调用shutdown，shutdown的第二个参数为SHUT_WR时，为半关闭。

TCP和UDP建立服务器的系统调用

TCP编程的服务器端一般步骤是： TCP包头的最小长度，为20字节。
　　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编程步骤要简单许多，分别如下：
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、关闭网络连接；

TCP保证可靠性：

· 确认应答机制
· 超时重传机制
· 流量控制
· 拥塞窗口

确认应答机制

在将这部分的内容之前我们应该首先知道的一点就是，在TCP中，TCP将每个字节的数据都进行了编号，即为序列号（对每一个数据的编号）。

由图分析：当主机1给主机2发送了1~1000这么多数据时，主机2如果收到了就会给主机1应答（ACK报文段，每一个ACK都带有对应的确认序列号），表示你给我发的1~1000的数据我已经全部收到了（收到哪些数据），下次你再给我发就给我从1001数据开始发（下次从哪里开始发）。那么主机1收到应答之后就知道对方已经收到了1~1000的全部数据，所以再一次发送数据的时候他就会从1001开始发，后面都是依此类推的情况。

当然了，当我们的主机1给主机2发送了数据之后，经过一端时间主机1并没有收到主机2的应答的情况也是有的，所以这个时候为了确保数据的准确到达，TCP就有了超时重传机制。

超时重传机制

主机1没有收到主机2的确认应答有以下两种情况：
1、数据根本就没有传送到达主机2，因此主机2就不会回传一个确认应答的报文。

由图分析：主机1给主机2发送了数据，可能因为其他的原因数据无法到达主机2.（比如网络拥堵）。这个时候主机1等待了一个特定的时间间隔之后发现主机2还没有确认应答，于是就再一次将上一次的数据重新发送过去。

2、主机2收到了数据，也回传了确认应答报文，但是该报文丢失了。

由图分析：主机2收到了主机1发来的数据，但是发给主机1的确认应答并没有准时到达主机1，所以主机1也会因为没有收到确认应答而再次重新将数据发送过去。但实际情况却是我们的主机2第一次就已经收到了主机1的数据。但是主机1依旧会重发数据已确保主机2已经收到数据，从而进行下一次的数据转发。可想而知主机2就会收到很多的重复数据，但是重复的数据显然是不需要的，那么TCP协议就需要能够识别那些重复的数据并且要将冲符的数据丢弃掉，这个时候序列号就发挥他的一项作用了——去重。每一个数据都有自己的序列号，如果主机2收到重复的数据那么必然机会产生多个序列号相同的数据，那么序列号相同的数据就必然是重复的数据。

流量控制

接收端处理数据的速度是优先的，如果发送端发的太快，导致接收端的缓冲区被打满，这个时候如果发送端继续发送就会造成丢包，继而引起丢包重传等一系列连锁反应。因此TCP支持根据接收端的处理能力，来决定发送端的发送速度，这个机制就叫做流量控制。
接收端将自己可以接受的缓冲区大小放入TCP首部中的“窗口大小”字段，通过ACK段通知发送端；
窗口大小字段越大，说明网络的吞吐量越高
接收端一旦发现自己的缓冲区快满了就会将窗口大小设置成一个更小的值通知发送端。
发送端接收到窗口大小以后，就会减慢自己的发送速度。
如果接收缓冲区满了，就会将窗口置为0，这时发送方不再发送数据。
但是需要定期的发送一个试探窗口，，目的是为了取探测数据段，是接收端把窗口大小告诉发送端。
接收端是如何把窗口大小告诉发送端的呢？TCP的报头格式，在TCP的首部中有一个16位的窗口大小的字段，就是存放的窗口大小的信息。另外在TCP的首部中的40字节选项中还包含了一个窗口扩大因子M，实际的窗口大小是窗口字段的值左移M位。

拥塞窗口

在后面会讲到TCP提高性能的滑动窗口，滑动窗口能够高效可靠的发送大量的数据，但是如果在一开始就发送大量的数据任然可能引发问题。要知道在网络上有很多的计算机，有可能当前的网络状态已经很拥堵，在不清楚当前的网络状态下，贸然发送大量的数据，这样对于已经很拥堵的网络来说无疑是雪上加霜。
由此，TCP引入了慢启动机制：先发送少量的数据，由此取探测当前的网络的拥堵状态，在决定按照多大的速度传输数据。
拥塞窗口：
发送开始的时候定义拥塞窗口大小为1
每当收到一个ACK应答以后拥塞窗口加1
每次发送数据包的时候，将拥塞窗口和接收端主机反馈的窗口大小作比较，取较小值作为实际发送的窗口。
如图，拥塞窗口的增长速度呈指数形式增长，我们提到说慢启动，只是说出事的时候慢而已，但是增长速度非常的快。
为了增长的不呢么快，因此我们不能让拥塞窗口单纯的加倍，这里引入一个慢启动的阈值，当同色窗口超过这个阈值的时候，不再按照指数方式增长，而是改为按照线性的方式增长。
当TCP开始启动的时候，慢启动阈值等于窗口最大值，在每次超时重发的时候，慢启动阈值会变成原来的一半，同时拥塞窗口置为1。
少量的丢包，仅仅只会触发超时重传，而大量的丢包就认为是网络拥堵，当TCP通信开始后，网络吞吐量会逐渐的上升，随着网络发生拥堵，吞吐量会立刻下降，拥塞控制说到底就是TCP协议想尽可能快的将数据传输给对方，但又要避免给网络造成太大的压力的折中解决办法。

HTTP和HTTPS的区别，以及HTTPS有什么缺点

HTTP协议和HTTPS协议区别如下：
1）HTTP协议是以明文的方式在网络中传输数据，而HTTPS协议传输的数据则是经过TLS加密后的，HTTPS具有更高的安全性
2）HTTPS在TCP三次握手阶段之后，还需要进行SSL 的handshake，协商加密使用的对称加密密钥
3）HTTPS协议需要服务端申请证书，浏览器端安装对应的根证书
4）HTTP协议端口是80，HTTPS协议端口是443
HTTPS优点：
HTTPS传输数据过程中使用密钥进行加密，所以安全性更高
HTTPS协议可以认证用户和服务器，确保数据发送到正确的用户和服务器
HTTPS缺点：
HTTPS握手阶段延时较高：由于在进行HTTP会话之前还需要进行SSL握手，因此HTTPS协议握手阶段延时增加
HTTPS部署成本高：一方面HTTPS协议需要使用证书来验证自身的安全性，所以需要购买CA证书；
                另一方面由于采用HTTPS协议需要进行加解密的计算，占用CPU资源较多，需要的服务器配置或数目高
HTTP返回码

HTTP协议的响应报文由状态行、响应头部和响应包体组成，其响应状态码总体描述如下：

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

200("OK")
一切正常。实体主体中的文档（若存在的话）是某资源的表示。

500("Bad Request")
客户端方面的问题。实体主题中的文档（若存在的话）是一个错误消息。希望客户端能够理解此错误消息，并改正问题。

500("Internal Server Error")
服务期方面的问题。实体主体中的文档（如果存在的话）是一个错误消息。该错误消息通常无济于事，因为客户端无法修复服务器方面的问题。

301("Moved Permanently")
当客户端触发的动作引起了资源URI的变化时发送此响应代码。另外，当客户端向一个资源的旧URI发送请求时，也发送此响应代码。

404("Not Found") 和410("Gone")
当客户端所请求的URI不对应于任何资源时，发送此响应代码。404用于服务器端不知道客户端要请求哪个资源的情况；410用于服务器端知道客户端所请求的资源曾经存在，但现在已经不存在了的情况。

409("Conflict")
当客户端试图执行一个”会导致一个或多个资源处于不一致状态“的操作时，发送此响应代码。

IP地址作用，以及MAC地址作用

MAC地址是一个硬件地址，用来定义网络设备的位置，主要由数据链路层负责。

IP地址是IP协议提供的一种统一的地址格式，为每一个网络和每一台主机分配一个逻辑地址，以此屏蔽物理地址的差异。

搜索baidu，会用到计算机网络中的什么层？每层是干什么的

浏览器中输入URL
浏览器要将URL解析为IP地址，解析域名就要用到DNS协议，首先主机会查询DNS的缓存，如果没有就给本地DNS发送查询请求。
DNS查询分为两种方式，一种是递归查询，一种是迭代查询。
如果是迭代查询，本地的DNS服务器，向根域名服务器发送查询请求，根域名服务器告知该域名的一级域名服务器，
然后本地服务器给该一级域名服务器发送查询请求，然后依次类推直到查询到该域名的IP地址。
DNS服务器是基于UDP的，因此会用到UDP协议。
得到IP地址后，浏览器就要与服务器建立一个http连接。
因此要用到http协议，http协议报文格式上面已经提到。
http生成一个get请求报文，将该报文传给TCP层处理，所以还会用到TCP协议。
如果采用https还会使用https协议先对http数据进行加密。
TCP层如果有需要先将HTTP数据包分片，分片依据路径MTU和MSS。
TCP的数据包然后会发送给IP层，用到IP协议。
IP层通过路由选路，一跳一跳发送到目的地址。
当然在一个网段内的寻址是通过以太网协议实现(也可以是其他物理层协议，比如PPP，SLIP)，
以太网协议需要直到目的IP地址的物理地址，有需要ARP协议。

IP层怎么知道报文该给哪个应用程序，它怎么区分UDP报文还是TCP报文

根据端口区分；

看ip头中的协议标识字段，17是udp，6是tcp

TIME_WAIT状态

tcp结束连接怎么握手，TIME_WAIT状态是什么,为什么会有TIME_WAIT状态？哪一方会有TIME_WAIT状态，如何避免TIME_WAIT状态占用资源(同理，CLOSE_WAIT)

什么时候会TIME_WAIT

TCP在关闭的时候有个四次挥手的过程，主动关闭方在四次挥手的最后一个ACK发送之后会变成TIME_WAIT状态。

主动关闭方

跟握手不同，挥手可以由客户端发起，也可以是服务端发起。发起关闭的一端我们称之为主动关闭方，另一端称之为被动关闭方。

四次挥手
主动关闭方会发送一个FIN给被动关闭方，表示数据已经发送完毕。
被动关闭方接收到FIN，响应一个ACK。它的接收作为一个文件结束符（end-of-file）传递给接收端应用进程（放在所有已排队等候该应用进程接收的任何其他数据之后）。FIN意味着接收端在相应连接上再无额外的数据可以接收了。
一段时间后，被动关闭方的应用进程收到了文件结束符，发送完所有需要发送的内容，也会发送一个FIN给主动关闭方。
接收到这个最终的FIN的主动关闭方也需要响应一个ACK。

TIME_WAIT状态维持多久

主动关闭方响应完最后一次ACK之后，会在TIME_WAIT这个状态维持2MSL。

为什么需要TIME_WAIT
可靠地实现了TCP全双工连接的终止
我们知道，TCP是比较可靠的。当TCP向另一端发送数据时，他要求对端返回一个确认（如同我们关闭时候的FIN和ACK）。如果没有收到确认，则会重发。

回忆一下我们最终的那个FIN与ACK，被动关闭方发送FIN，并等待主动关闭方返回的ACK。我们假设最终的ACK丢失，被动关闭方将需要重新发送它的最终那个FIN，主动关闭方必须维护状态信息（TIME_WAIT），以允许它重发最终的那个ACK。

如果没有了这个状态，当他第二次收到FIN时，会响应一个RST（也是一种类型的TCP分节），会被服务器解释成一个错误。

为了TCP打算执行必要的工作以彻底终止某个连接两个方向上的数据流（即全双工关闭），那么他必须要正确处理连接终止四个分节中任何一个分节丢失的情况。

允许老的重复分节在网络中的消逝（为什么需要2MSL）
首先，存在这样的情况，某个路由器崩溃或者两个路由器之间的某个链接断开时，路由协议需要花费数秒到数分钟的时间才能稳定找出另一条通路。在这段时间内，可能发生路由循环（路由器A把分组发送给B，B又发送回给A），这种情况我们称之为迷途。假设迷途的分组是一个TCP分节，在迷途期间，发送端TCP超时并重传该分组，重传分组通过某路径到达目的地，而后不久（最多MSL秒）路由循环修复，早先迷失在这个循环中的分组最终也被送到目的地。这种分组被称之为重复分组或者漫游的重复分组，TCP必须要正确处理这些重复的分组。

我们假设ip1:port1和ip2:port2 之间有一个TCP连接。我们关闭了这个链接，过一段时间后在相同IP和端口之间建立了另一个连接。TCP必须防止来自之前那个连接的老的重复分组在新连接上出现。为了做到这一点，TCP将不复用处于TIME_WAIT状态的连接。2MSL的时间足以让某个方向上的分组存活MSL秒后被丢弃，另一个方向上的应答也最多存活MSL秒后被丢弃。

socket什么情况下可读/可写？

一、下列四个条件中的任何一个满足时,socket准备好读:

1. socket的接收缓冲区中的数据字节大于等于该socket的接收缓冲区低水位标记的当前大小

2. 该连接的读这一半关闭(也就是接收了FIN的TCP连接)。对这样的socket的读操作将不阻塞并返回0

3. socket是一个用于监听的socket,

4. 有一个socket有异常错误条件待处理.

二、下列三个条件中的任何一个满足时,socket准备好写:

socket的发送缓冲区中的数据字节大于等于该socket的发送缓冲区低水位标记的当前大小。

该连接的写这一半关闭。

有一个socket异常错误条件待处理.

tcp socket什么情况下表示对端关闭

用setsockopt设置超时,在规定时间内根据返回值判断connect不上或者send不成功就是网络故障或者对方关闭了socket.

backlog的作用

backlog曾经的含义：已完成队列和未完成队列里边条目之和不能超过 backlog;

Linux 2.2 后backlog这个参数指示的是存放已经建立连接（established）并等待被accept的sockets的队列的长度。

http怎么实现的断点续传

就是在Http的请求上多定义了断点续传相关的HTTP头 Range和Content-Range字段

  1. 客户端下载一个1024K的文件，已经下载了其中512K
  2. 网络中断，客户端请求续传，因此需要在HTTP头中申明本次需要续传的片段：
           Range:bytes=512000-
           这个头通知服务端从文件的512K位置开始传输文件
  3. 服务端收到断点续传请求，从文件的512K位置开始传输，并且在HTTP头中增加：
           Content-Range:bytes 512000-/1024000
           并且此时服务端返回的HTTP状态码应该是206，而不是200。

tcp头多少字节（20）？哪些字段?

tcp套接字选项，并说明其作用

SO_LINGER

本选项指定close函数对面向连接的协议（例如TCP和SCTP，但不是UDP）如何操作。
默认操作是close立即返回，但是如果有数据残留在套接字发送缓冲区中，系统将试着把这些数据发送给对端。

SO_KEEPALIVE

设置保持存活选项后，如果2小时内在该套接字的任何一方向上都没有数据交换，TCP就自动给对端发送一个保持存活探测分节。
这是一个对端TCP必须响应的TCP分节，会导致以下三种情况：
           1、对端响应ACK，应用进程也不会得到任何通知（因为一切正常），接下来2小时若仍无动静，TCP将再次发送分节
           2、对端以RST响应，它告知本端TCP：对端已崩溃且已重新启动。该套接字的待处理错误被置为ECONNRESET，套接字本身则被关闭
           3、对端没有任何响应，TCP将另外发送8个探测分节，两两相隔75秒，在发出第一个探测分节后11分15秒内没有得到任何响应则放弃，待处理错误为ETIMEOUT，套接字本身被关闭
              然而如果收到一个ICMP错误作为某个探测分节的响应，那就返回相应错误，套接字被关闭。（常见的ICMP错误为“主机不可达”）
本选项的公用是检测对端主机是否崩溃或变得不可达。
如果对端进程崩溃，它的TCP将跨连接发送一个FIN，这可以通过select很容易检测到。
同时也要认识到，即使对任何探测无响应，我们也不能认定主机崩溃，因而TCP可能会终结一个有效的连接。
某个中间路由崩溃一段时间也是有可能的
本选项一般由服务器使用。（客户端也可）

SO_SENDBUF、SO_RECVBUF

//每个套接口都有一个发送缓冲区和一个接收缓冲区，使用这两个套接口选项可以改变缺省缓冲区大小

SO_RESUEADDR、SO_REUSEPORT

//SO_REUSEADDR的能力：
 
  //（1）SO_REUSEADDR允许启动一个监听服务器并捆绑其端口，即使以前建立的将端口用作他们的本地端口的连接仍旧存在；
 
                 //【即便TIME_WAIT状态存在，服务器bind()也能成功】
 
  //（2）允许同一个端口上启动同一个服务器的多个实例，只要每个实例捆绑一个不同的本地IP地址即可；
 
  //（3）SO_REUSEADDR允许单个进程捆绑同一个端口到多个套接字，只要每次捆绑指定不同的本地IP地址即可；
 
  //（4）SO_REUSEADDR允许完全重复的绑定：当一个IP地址和端口已经绑定到某个套接字上时，如果传输协议支持

妖渊

关注

0
点赞
踩
5

收藏

觉得还不错? 一键收藏
0
评论
后台开发面试-计算机网络(一)

目录TCP和UDP的区别TCP三次握手和四次挥手1、三次握手（1）三次握手的详述（2）总结三次握手过程：（3）为什么A还要发送一次确认呢？可以二次握手吗？（4）Server端易受到SYN攻击？2、四次挥手（1）四次挥手的详述（2）总结四次挥手过程：（3）为什么A在TIME-WAIT状态必须等待2MSL的时间？（4）为什么连接的时候是三次握手，关闭的时...
复制链接

扫一扫