从输入URL到页面显示发生了什么？
当你在浏览器输入一个URL 发生了什么？
详细过程：
- 浏览器通过DNS域名解析到服务IP
- 客户端（浏览器）通过TCP协议建立到服务器的TCP连接；(三次握手)
- 客户端（浏览器）向web服务器端（HTTP服务器）发送HTTP 协议包，请求服务器里的资源文档(telnet模拟)
- 服务器向客户端发送HTTP协议应答包
- 客户端和服务器断开（四次挥手），客户端开始解析HTML文档
http要请求成功，必须通过TCP的三次握手才能与服务器连接。
http连接成功要基于TCP，
三次握手：首先客户端发送一个SYM的数据包， (seq = client-isn)然后客户端就处于一个send的状态，然后客户端就等服务器给它一个确认 ，这是第一次握手；二次握手，服务器收到包之后，必须确认客户端SYM包，怎样确认的呢？先把SYM包转换成ACK包，ACK包会把刚才seq包+1，同时自己会发送sym包，然后客户端会收到，确实是之前自己发送的包，并且加了1返回。拿到SYM包之后它也把SYM包加1给返回出去了。这个时候三次握手建立完成。
1、先Client 发送连接、请求报文。
2、Server端接受连接后回复ACK报文，并为此次连接分配资源
3、Client端接受ACK报文之后也向服务器端发送ACK报文，并分配资源，这样TCP就建立了。
四次挥手：
1、Client 端发起中断连接请求，也就是发送FIn报文。Server端接到FIN报文之后，意思是说：“我Client端没有数据要发给你了”，但是如果你还有数据没发送完成，则不必急着关闭（Socket）,可以继续发送数据。
2、Server发送ACK，告诉Clien端，“你的请求我收到了，但是我还没准备号，请继续等我的消息”。
wait：这个时候Client端就进入FIN_WAIT撞他，继续等待Server站的FIN报文。
3、当Server端确定数据已发送完成，则向Client端发送FIN报文，告诉Client端，”好了，我这边数据发送完了，准备好关闭连接了“。
4、客户端收到FIN报文后，就知道可以关闭连接了，但是它还是不相信网络，怕Server端不知道要关闭，所以发送ACK后进入TIME_Wait状态。如果Server端没有收到ACk则可以重传。Server端收到ACK后，就知道可以断开连接了。客户端等待2MSL后没有收到回复，则证明Server端已正常关闭。那么我（客户端）也可以关闭连接了。这样TCP连接就这样关闭。
fin 表示断开连接 ACK表示响应
报文：发送报文，响应也用报文
为什么客户端在TIME_WAIT状态必须等待2MSL时间呢？
1、第一，为了保证客户端发送的最后一个ACK报文段能够到达Server端。这个ACK报文段有可能丢失，因而使服务器端收不到已经发送的ACK报文段的确认。B超时重传这个FIN ，客户端就能在2MSL时间内收到这个重传的FIN，接着客户端还要重传一次确认，重新启动2MSL计时。如果客户端不在TIME_WAIT等待一段时间，而是在发送完ACK报文段后立即释放连接，就无法收到服务器端重传的FIN，因而也不会再发送一次确认报文段。这样B就不能正常关闭。
2、第二，防止“已失效的连接请求报文段”出现在本连接中。客户端发送完最后一个ACK报文段后，再经过时间2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网路消失。这样就可以使下一个新的连接中不会出现这种的连接请求报文段。
已经失效的连接请求报文段是这样产生的
考虑到一种正常情况：
客户端发出连接请求，但因连接请求报文丢失而未收到确认。于是客户端再重传一次连接请求。后来收到确认，重新连接连接。数据传输完毕后，就释放了连接。客户端共发送了两个连接请求报文段，但是第一个丢失，第二个到达了B。
异常情况的考虑：
即客户端发出的第一个连接请求报文段没有丢失，而是在某些网络结点长时间滞留了，以致延误到连接释放以后的某个时间才到达服务器。本来这是一个早已失效的报文段，但是服务器收到此失效的连接请求报文段之后，误认是客户端重新发送的新的请求。于是就向Client发出确认报文段，同意建立连接。因为客户端没有发出建立连接请求，只是服务端收到报废的报文段，所以客户端不会理服务端的确认，这样服务端就一直在等待之中，许多资源就这样白白浪费。
注意：采用三次握手就可以防止“已失效的连接请求报文段”现象的发生。