整个流程如下：
域名解析
为了将消息从你的PC上传到服务器
上.需要用到1P协议、ARP协议和0SPF协议
发起TCP的3次握手
建立TCP连接后发起http请求
服务器响应htp请求
浏览器解析htm代码,并请求html代码中的资源(如js、css、图片等）
断开TCP连接
浏览器对页面进行渲染呈现给用户
一、域名解析的详细内部过程
例如，要查询www.baidu.com的IP地址（DNS解析url）：
浏览器搜索自己的DNS缓存（维护一张域名与IP地址的对应表）
若没有，则搜索操作系统中的DNS缓存（维护一张域名与IP地址的对应表）
若没有，则搜索操作系统的hosts文件（Windows环境下，维护一张域名与IP地址的对应表，位置一般在 C:WindowsSystem32driversetchosts）
若没有，则操作系统将域名发送至 本地域名服务器- -（递归查询方式），本地域名服务器 查询自己的DNS缓存，查找成功则返回结果，否则，（以下是迭代查询方式）
4.1 本地域名服务器 向根域名服务器（其虽然没有每个域名的具体信息，但存储了负责每个域，如com、net、org等的解析的顶级域名服务器的地址）发起请求，此处，根域名服务器返回com域的顶级域名服务器的地址
4.2 本地域名服务器 向com域的顶级域名服务器发起请求，返回baidu.com权限域名服务器（权限域名服务器，用来保存该区中的所有主机域名到IP地址的映射）地址
4.3 本地域名服务器 向baidu.com权限域名服务器发起请求，得到www.baidu.com的IP地址
本地域名服务器 将得到的IP地址返回给操作系统，同时自己也将IP地址缓存起来
操作系统将 IP 地址返回给浏览器，同时自己也将IP地址缓存起来
至此，浏览器已经得到了域名对应的IP地址
二、三次握手
第一次握手：主机A发送位码为syn＝1,随机产生seq number=x的数据包到服务器，客户端进入SYN_SEND状态，等待服务器的确认；主机B由SYN=1知道，A要求建立联机；
第二次握手：主机B收到请求后要确认联机信息，向A发送ack number(主机A的seq+1),syn=1,ack=1,随机产生seq=y的包,此时服务器进入SYN_RECV状态;
第三次握手：主机A收到后检查ack number是否正确，即第一次发送的seq number+1,以及位码ack是否为1，若正确，主机A会再发送ack number(主机B的seq+1),ack=1，主机B收到后确认seq值与ack=1则连接建立成功。客户端和服务器端都进入ESTABLISHED状
态，完成TCP三次握手。
TCP位码,有6种标示:SYN(synchronous建立联机) ACK(acknowledgement 确认) PSH(push传送) FIN(finish结束) RST(reset重置) URG(urgent紧急)
Sequence number(顺序号码) Acknowledge number(确认号码)
三、建立TCP连接后发起http请求
四、服务器收到请求并响应HTTP请求
1.负载均衡
网站可能会有负载均衡设备来平均分配所有用户的请求。即对工作任务进行平衡,分
摊到多个操作单元上执行,如图片服务器,应用服务器等。
2请求处理阅读请求及它的参数和 cookies
五.浏览器解析htm代码,并请求htm代码中的资源(如js、css图片等)
看是否是长连接。来决定是不是断开TCP连接
六.断开TCP连接
四次挥手
第一次挥手：主机1（可以使客户端，也可以是服务器端），设置Sequence Number和Acknowledgment Number，向主机2发送一个FIN报文段；此时，主机1进入FIN_WAIT_1状态；这表示主机1没有数据要发送给主机2了；
第二次挥手：主机2收到了主机1发送的FIN报文段，向主机1回一个ACK报文段，Acknowledgment Number为Sequence Number加1；主机1进入FIN_WAIT_2状态；主机2告诉主机1，我也没有数据要发送了，可以进行关闭连接了；
第三次挥手：主机2向主机1发送FIN报文段，请求关闭连接，同时主机2进入CLOSE_WAIT状态；
第四次挥手：主机1收到主机2发送的FIN报文段，向主机2发送ACK报文段，然后主机1进入TIME_WAIT状态；主机2收到主机1的ACK报文段以后，就关闭连接；此时，主机1等待2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，主机1也可以关闭连接了。
七.浏览器对页面进行渲染呈现给用户
重新温习下网络模型：
- 七层结构(至顶向下)：应用层、表示层、会话层、传输层、网络层、数据链路层、物理层
client(浏览器) 与Server 通过HTTP协议通讯，HTTP协议属于”应用层协议”;HTTP基于TCP协议，TCP通过Socket进行通讯,TCP 被称为“传输层协议”。而HTTPS 还需要走会话层SSLTLS等协议；传输层之下是网络层，这里主要是路由协议OSPF等进行路由选择，转发；再向下数据链路层主要是ARP、RARP协议完成IP和MAC地址互相解析，再向下是物理层主要是基于IEEE802.X等协议进行数据比特流转成高低电平的定义；
当浏览器发出请求时候，首先通过应用层DNS协议得到对应IP地址，在这经历全球路由大接力；而传输层TCP协议采用“三次握手”协议建立连接和“四次挥手”协议断开连接，然后数据链路层解析IP与MAC地址的映射；数据经过层层数据封包、解包过程，如下：
这里特别强调下三次握手建立连接，放图作为参考：
四次握手断开连接：
客户端发起 FIN ACK, 服务端应答 ACK, 待服务端数据发送完成后，发送FIN ACK, 客户端应答 ACK, 连接断开。
从应用服务角度分析
数据交换主要通过HTTP 协议， HTTP协议是无状态协议。多数通过GET、POST方法，GET与POST区别：
GET：请求获取指定的资源，不改变服务器状态，GET方法是幂等的，GET方法的报文主体没有任何语义。
POST: 根据请求报文主体对指定的资源做出处理，改变服务器状态，POST方法不幂等。
http方法不仅只有GET、POST， http1.1中含有如下方法：
RESTful API 就是利用这组方法来统一表述资源的状态转化。
同时，由于http无状态协议的特点，服务端需要记录用户时，就需要用某种机制来识具体的用户, 通常采用cookies、session。
session 本意是会话，是一个抽象概念。将 clinet 和 server 之间一对一的交互，抽象为“会话”，开发者为了实现一对一的“隔离”，中断和继续等操作，进而衍生出“会话状态”，也就是 session 的概念。
如何维护这个session概念，很自然的想到在http请求报文中加入登录标识就可以了，这个登录标识就是cookie。而 cookie 是一个实际存在的东西，http 协议中定义在 header 中的字段。这种技术的实现就是利用了cookie技术。 cookie是存储key-value对的一个文件，务必记住，它是由服务器将cookie添加到response里一并返回给客户端，然后客户端会自动把response里的cookie接收下来，并且保存到本地，下次发出请求的时候，就会把cookie附加在request里，服务器在根据request里的cookie遍历搜索是否有与之符合的信息。
cookie 虽然很方便，但是使用 cookie 有两个的弊端：
- cookie 中的所有数据在客户端就可以被修改。这就意味着数据非常容易被伪造，一些重要的数据就不能存放在 cookie 中;
- 如果 cookie 中数据字段太多会影响传输效率;
为了解决这些问题，就产生了 session，
session是一种服务器机制，使用Hash散列表结构来保存信息。
1. 每个 session 都对应一个 session_id，通过 session_id 可以查询到对应的 session;
2. session_id 通常是存放在客户端的 cookie 中，服务端存好 session 之后将对应的 session_id 设置在 cookie 中发送给客户端;
3. 当请求到来时，服务端检查 cookie 中保存的 session_id 并通过这个 session_id 与服务器端的 session 关联起来，进行数据的保存和修改;
这就是大多数人通常所说的session, 这里其实是指的 session实现。
server 端通常采用Nginx、Apache；
这里以PHP为例：
Nginx接收到请求，进行一些验证，如黑白名单拦截等， 是否有限流限制，是否有负载均衡设置；
如果请求的是静态内容,Nginx会将结果直接返回给用户。
如果请求的是动态内容,Nginx会将请求交给fastcgi客户端, 通过fastcgi_pass将这个请求发送给进程php-fpm。Nginx 不支持对外部动态程序的直接调用或者解析 ，所有的外部程序必须通过FastCGI接口来调用。