yunqi1215的博客

客户端首先发起DHCP发现报文（DHCP DISCOVER）的ip数据报，由于客户端没有ip地址，也不知道DHCP服务器的地址，所以使用的是UDP广播通信，其使用的广播目的地址是255.255.255.255（端口号67）并且使用0.0.0.0（端口68）作为源IP地址。客户端收到一个或多个服务器的DHCP提供报文后，从中选择一个服务器，并向选中的服务器发送DHCP请求报文（DHCP REQUEST）进行响应，回显配置的参数。最后，服务端用DHCP ACK报文对DHCP请求报文进行响应，应答所要求的参数。

服务端收到后，用RSA私钥解密，得到client发来的随机数，致此，client和server共享了三个随机数，双方根据三个随机数，生成会话秘钥，他就是对称秘钥，用于后续的http请求/响应的数据加解密。服务端为了证明自己的身份，会发送server certificate 给client，消息中包含有数字证书，随后，服务端发了serverhellodone消息，目的是告诉客户端，我已经把该给你的东西都给你了，本次打招呼完毕。但是，由于相同的密钥用于加密和解密，因此安全性依赖于密钥的安全性。

TCP/IP学习笔记，参考小林coding

快恢复算法规则：在接收到3个重复ack后，ssthresh设置为cwnd的一半，然后cwnd设置为ssthresh+3个MSS，这样做是为了反映在网络中还有传输的数据包，随后，对于接收到的每个重复ack，cwnd就递增一个MSS，当收到新ack时，将cwnd设置为ssthresh的值。TCP 在刚建立连接完成后，首先是有个慢启动的过程，这个慢启动的意思就是一点一点的提高发送数据包的数量，如果一上来就发大量的数据，这不是给网络添堵吗。就是重传的时候，是重传一个，还是重传所有的问题。

三次握手才可以阻止重复历史连接的初始化（主要原因）三次握手才可以同步双方的初始序列号三次握手才可以避免资源浪费第一次：A向B发请求，如果只有一次握手，A端不知道B端是不是收到了请求第二次：B端向A端收到请求，如果有二次握手的话，B端不知道A端是否收到确认信息，这个消息有可能在半路丢了第三次：A端收到B端确认消息，A和B双方都是通的，可以建联互相通信了不使用「两次握手」和「四次握手」的原因：「两次握手」：无法防止历史连接的建立，会造成双方资源的浪费，也无法可靠的同步双方序列号；