计算机网络

计算机网络

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

可读:

socket接收缓冲区中已经接收的数据的字节数大于等于socket接收缓冲区低水位标记的当前值;对这样的socket的读操作不会阻塞,并返回一个大于0的值(准备好读入的数据的字节数).
连接的读半部关闭(即:接收到对方发过来的FIN的TCP连接),并且返回0;
socket为监听套接字且收到了对方的connect请求已经完成的连接数为非0.这样的soocket处于可读状态；
存在一个套接字错误待处理，这时socket的读操作将不会阻塞,并且返回一个错误(-1)。

可写:

socket发送缓冲区中的可用空间字节数大于等于socket发送缓冲区低水位标记的当前值,且(i):socket已连接(TCP socket),或者(ii):socket不要求连接(如:UDP socket).这意味着,如果我们将这样的socket设置为非阻塞模式,写操作将不会阻塞,并且返回一个正值(如:由传输层接收的字节数).我们可以用socket选项SO_SNDLOWAT来设置此低水位标记,对于TCP和UDP socket,其缺省值一般是2048Bytes;
连接的写半部关闭.对于这样的socket的的写操作将产生信号SIGPIPE;
使用非阻塞式connect的套接字已经建立连接，或connect已经以失败告终；
存在一个套接字错误待处理.对于这样的socket的写操作将不会阻塞并且返回一个错误(-1),errno则设置成明确的错误条件.这些待处理的错误也可以通过指定socket选项SO_ERROR调用getsockopt函数来取得并清除。

udp调用connect有什么作用？

因为UDP可以是一对一，多对一，一对多，或者多对多的通信，所以每次调用sendto()/recvfrom()时都必须指定目标IP和端口号。通过调用connect()建立一个端到端的连接，就可以和TCP一样使用send()/recv()传递数据，而不需要每次都指定目标IP和端口号。但是它和TCP不同的是它没有三次握手的过程。
可以通过在已建立连接的UDP套接字上，调用connect()实现指定新的IP地址和端口号以及断开连接。

请回答一下HTTP和HTTPS的区别，以及HTTPS有什么缺点？

HTTP协议和HTTPS协议区别如下:

HTTP协议是以明文的方式在网络中传输数据，而HTTPS协议传输的数据则是经过TLS (Transport Layer Security,安全传输层协议)加密后的，HTTPS具有更高的安全性
HTTPS在TCP三次握手阶段之后，还需要进行SSL(Secure Sockets Layer 安全套接字协议)的handshake，协商加密使用的对称加密密钥
HTTPS协议需要服务端申请证书，浏览器端安装对应的根证书
HTTP协议端口是80，HTTPS协议端口是443

HTTPS优点:

HTTPS传输数据过程中使用密钥进行加密，所以安全性更高
HTTPS协议可以认证用户和服务器，确保数据发送到正确的用户和服务器

HTTPS缺点:

HTTPS握手阶段延时较高: 由于在进行HTTP会话之前还需要进行SSL握手，因此HTTPS协议握手阶段延时增加
HTTPS部署成本高: 一方面HTTPS协议需要使用证书来验证自身的安全性，所以需要购买CA证书；另一方面由于采用HTTPS协议需要进行加解密的计算，占用CPU资源较多，需要的服务器配置或数目高

IP地址作用和MAC地址作用

MAC地址是一个硬件地址，用来定义网络设备的位置，主要由数据链路层负责。而IP地址是IP协议提供的一种统一的地址格式，为互联网上的每一个网络和每一台主机分配一个逻辑地址，以此来屏蔽物理地址的差异。

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

浏览器要将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协议。

从输入URL到页面展示的详细过程：

输入网址
DNS解析
建立tcp连接
客户端发送HTTP/HTTPS请求
服务器处理请求
服务器响应请求
浏览器展示HTML
浏览器发送请求获取其他在HTML中的资源。

请问tcp握手为什么两次不可以？为什么不用四次？

两次不可以：tcp是全双工通信，两次握手只能确定单向数据链路是可以通信的，并不能保证反向的通信正常不用四次：本来握手应该和挥手一样都是需要确认两个方向都能联通的，本来模型应该是： 1.客户端发送syn0给服务器 2.服务器收到syn0，回复ack(syn0+1) 3.服务器发送syn1 4.客户端收到syn1，回复ack(syn1+1) 因为tcp是全双工的，上边的四部确认了数据在两个方向上都是可以正确到达的，但是2，3步没有没有上下的联系，可以将其合并，加快握手效率，所有就变成了3步握手。

不可以是两次握手：

当客户端向服务器端发送一个连接请求时，由于某种原因长时间驻留在网络节点中，无法到达服务器端，由于TCP的超时重传机制，当客户端在特定的时间内没有收到服务器端的的确认应答时，就会重新向服务器端发送连接请求，该请求到达服务器端并建立连接，进行数据传输，当数据传输完成时，释放了TCP连接。

若此时第一次的连接请求报文段延迟了一段时间后到达了服务器端，本来这是一个很早到达的失效的报文段，但是服务器端收到了该链接请求后误以为是客户端重新又发起了一次连接请求，于是服务器端发出确认应答报文段，并表示同意建立连接。如果没有第三次握手，由于服务器端发送了确认应答信息，则表示新的连接建立成功，但是客户端并没有向服务器端发送任何建立请求，客户端将忽略服务器端的确认报文，更不会发送任何请求或数据。而服务器端认为建立成功了，并一直在等待建立连接，直到超出计数器的设定值，则认为服务器端出现了异常，并关闭此链接。这个等待的过程中，浪费了服务器端的资源。

请问TCP三次握手是怎样的？

客户端发送syn0给服务器
服务器收到syn0，回复syn1,ack(syn0+1)
客户端收到syn1，回复ack(syn1+1)

四次挥手

客户端发送fin
服务端收到fin,回复ack,然后服务器去处理其他事（Server端所有的报文都发送完了，才能发送FIN报文）
服务器事情处理完，回复fin
客户端回复ack

客户端：发送FIN报文（FIN = 1），序列号为u（seq = u），进入FIN-WAIT 1状态。

服务器：发送ACK确认报文（ACK = 1），序列号为v（seq = v），确认报文u（ack = u + 1），进入CLOSE-WAIT状态，继续传送数据。

客户端：收到上述报文进入FIN-WAIT2状态，继续接受B传输的数据。

服务器：数据传输完毕后，发送FIN报文（FIN = 1，ACK = 1），序列号为w（seq = w），确认报文u（ack = u + 1），进入LAST-ACK状态。

客户端：发送ACK确认报文（ACK = 1），序列号为u+1（seq = u + 1），确认报文w（ack = w + 1），进入TIME-WAIT状态，等待2MSL（最长报文段寿命），进入CLOSED状态。

服务器：收到后上述报文后进入CLOSED状态。

为什么客户端不发送报文段后直接关闭，而是要等待2MSL个时间后才关闭？，是否有必要？

若客户端发送完最后一次报文后，也就是第四次挥手后就直接进入关闭状态，此时若第四次挥手报文丢失，会导致服务器的超时重传。
此时客户端又已经关闭，导致不接受该报文，因此服务器会一直不断重传，并一直处于最后确认状态无法进入关闭状态。

因此，有以下结论：客户端进入时间等待状态以及处于该状态2MSL时长，可以确保TCP服务器进程可以收到最后一个TCP确认报文段而进入关闭状态。

TCP客户进程在发送完最后一个TCP确认报文段后，在经过2MSL时长，就可以使本次连接持续时间内所产生的所有报文段都从网络中消失，这样就可以使使下一个新的TCP连接中，不会出现旧连接中的报文段。

若出现这样一种情况：

TCP双方已经建立了连接，但是传输过程中TCP客户进程所在的主机出现了故障，此时TCP服务器进程以后就不能再收到TCP客户进程发来的数据，这时服务器进程会一直处于等待状态。

为了使TCP服务器进程不要再白白等待下去出现了TCP保活计时器：

cookie,session与token的区别 →