一共抓到11个包，浏览器使用的端口是52085，服务器使用的端口是80，经过SYN、SYN/ACK、ACK的三个包之后建立连接，浏览器第四个包TCP发送了一个“GET / HTTP/1.1”请求报文，Web服务器回复了第五个包，在TCP协议层面确认：“刚才的报文我已经收到了”，不过这个TCP包HTTP协议是看不见的，服务器从磁盘上把那个文件全读出来，再拼成符合HTTP格式的报文，发回去吧这就是的第六个包“HTTP/1.1 200 OK”，底层走的还是TCP协议，这时浏览器就收到了响应数据，但里面是什么呢？所以也要解析报文。一看，服务器给我的是个
HTML文件，好，那我就调用排版引擎、JavaScript引擎等等处理一下，然后在浏览器窗口里展现出了欢迎页面
浏览器 服务器 DNS
CDN插上一脚，CDN会缓存网站的大部分资源，比如图片、CSS样式表，所以有的HTTP请求就不需要再发到Apple，CDN就可以直接响应你的请求，把数据发给你，单手CDN无法缓存动态资源，HTTP请求只能经过无数的路由器、网关、代理，最后到达目的地，目标网站的服务器对外表现的是一个IP地址，但为了能够扛住高并发，在内部也是一套复杂的架
构。通常在入口是负载均衡设备，例如四层的LVS或者七层的Nginx，在后面是许多的服务器，构成一个更强更稳定的集群。负载均衡设备会先访问系统里的缓存服务器，通常有memory级缓存Redis和disk级缓存Varnish，它们的作用与CDN类似，不过是工作在内部网络里，把最频繁访问的数据缓存几秒钟或几分钟，减轻后端应用服务器的压力。如果缓存服务器里也没有，那么负载均衡设备就要把请求转发给应用服务器了。这里就是各种开发框架大显神通的地方了，例如Java的Tomcat/Netty/Jetty，Python的Django，还有PHP、
Node.js、Golang等等。它们又会再访问后面的MySQL、PostgreSQL、MongoDB等数据库服务，实现用户登录、商品查询、购物下单、扣款支付等业务操作，然后把执行的结果返回给负载均衡设备，同时也可能给缓存服务器里也放一份。应用服务器的输出到了负载均衡设备这里，请求的处理就算是完成了，就要按照原路再走回去，还是要经过许多的路由器、网关、代理。如果这个资源允许缓存，那么经过CDN的时候它也会做缓存，这样下次同样的请求就不会到达源站了。最后网站的响应数据回到了你的设备，它可能是HTML、JSON、图片或者其他格式的数据，需要由浏览器解析处理才能显示出来，如果数据里面还有超链接，指向别的资源，那么就又要重走一遍整个流程，直到所有的资源都下载完。
Host：请求字段，只能出现在请求头。是必须出现的字段
User-Agent：是请求字段，只能出现在请求头里。
Date：是通用字段，通常出现在响应头，标识HTTP报文创建的时间，客户端可以使用这个时间再搭配其他字段决定缓存策略
Server字段是响应字段，只能出现在响应头里。告诉客户端当前正在提供Web服务的软件名称和版本号。
Content-Length：标识报文里body的长度。
GET方法在URI后使用“#”，就可以在获取页面后直接定位到某个标签所在的位置；使用If-Modified-Since字段就变成了“有条件的请求”，仅当资源被修改时才会执行获取动作；使用
Range字段就是“范围请求”，只获取资源的一部分数据。
HEAD 只获取响应头
GET 获取 select
POST insert
PUT update
Delete delete
CONNECT 要求服务器为客户端和另一台远程服务器建立一条特殊的连接隧道，这时Web服务器在中间充当了代理的角色。
OPTIONS方法要求服务器列出可对资源实行的操作方法，在响应头的Allow字段里返回,用到，CORS跨域请求
TRACE方法多用于对HTTP链路的测试或诊断，可以显示出请求-响应的传输路径
可以根据需要扩展方法
安全与幂等
安全:对服务器上的资源只读,get
幂等 多次执行相同的操作，结果也都是相同的，即多次“幂”后结果“相等”。POST是“新增或提交数据”，多次提交数据会创建多个资源，所以不是幂等
的；而PUT是“替换或更新数据”，多次更新一个资源，资源还是会第一次更新的状态，所以是幂等的。
客户端和服务器看到的URI是不一样的。客户端看到的必须是完整的URI，使用特定的协议去连接特定的主机，而服务器看到的只是报文请求行里被删除了协议名和主机名的URI。
如果你配置过Nginx，你就应该明白了，Nginx作为一个Web服务器，它的location、rewrite等指令操作的URI其实指的是真正URI里的path和后续的部分。
URI的编码：直接把非ASCII 码或特殊字符转换成十六进制字节值，然后前面加一个“%”，中文、日文等通常使用UTF-8编码后再转义。
101 客户端使用Upgrade头字段升级websocket
200 OK
204 No Content(没有body数据)
206 Partial Content 是HTTP分块下载或断点续传的基础，在客户端发送“范围请求”、要求获取资源的部分数据时出现，它与200一样，也是服务器成功处理了请求，但body里的数据不是资源的全部，而是其中的一部分。状态码206通常还会伴随着头字段“Content-Range”，表示响应报文里body数据的具体范围.客户端确认，例如“Content-Range: bytes 0-99/2000”，意思是此次获取的是总计2000个字节的前100个字节。
301 Moved Permanently 的网站升级到了HTTPS，原来的HTTP不打算用了
和302都会在响应头里使用字段Location指明后续要跳转的URI
302 Found 临时 今天夜里网站后台要系统维护，服务暂时不可用，这就属于“临时”的，可以配置成302跳转，把流量临时切换到一个静态通知页面，浏览器看到这个302就知道这只是暂时的情况，不会做缓存优化，第二天还会访问原来的地址。
“304 Not Modified” 是一个比较有意思的状态码，它用于If-Modified-Since等条件请求，表示资源未修改，用于缓存控制。它不具有通常的跳转含义，但可以理解成“重定向已到缓存的文件”（即“缓存重定向”）
“400 Bad Request”是一个通用的错误码，表示请求报文有错误，但具体是数据格式错误、缺少请求头还是URI超长它没有明确说，只是一个笼统的错误
403 Forbidden”实际上不是客户端的请求出错，而是表示服务器禁止访问资源。原因可能多种多样，例如信息敏感、法律禁止等
404 Not Found”可能是我们最常看见也是最不愿意看到的一个状态码，它的原意是资源在本服务器上未找到，所以无法提供给客户端
405 Method Not Allowed：不允许使用某些方法操作资源，例如不允许POST只能GET；
406 Not Acceptable：资源无法满足客户端请求的条件，例如请求中文但只有英文；
408 Request Timeout：请求超时，服务器等待了过长的时间；
409 Conflict：多个请求发生了冲突，可以理解为多线程并发时的竞态；
413 Request Entity Too Large：请求报文里的body太大；
414 Request-URI Too Long：请求行里的URI太大；
429 Too Many Requests：客户端发送了太多的请求，通常是由于服务器的限连策略；
431 Request Header Fields Too Large：请求头某个字段或总体太大；
500 Internal Server Error 与404类似，通用错误
501 Not Implemented”表示客户端请求的功能还不支持，这个错误码比500要“温和”一些，和“即将开业，敬请期待”的意思差不多，不过具体什么时候“开业”就不好说了。
“502 Bad Gateway”通常是服务器作为网关或者代理时返回的错误码，表示服务器自身工作正常，访问后端服务器时发生了错误，但具体的错误原因也是不知道的。
“503 Service Unavailable”表示服务器当前很忙，暂时无法响应服务，我们上网时有时候遇到的“网络服务正忙，请稍后重试”的提示信息就是状态码503。
503是一个“临时”的状态，很可能过几秒钟后服务器就不那么忙了，可以继续提供服务，所以503响应报文里通常还会有一个“Retry-After”字段，指示客户端可以在多久以后再次尝试送请求。
HTTP
1 灵活可扩展
2 “可靠”的传输协议 具体做法与TCP/UDP差不多，都是对实际传输的数据（entity）做了一层包装，加上一个头，然后调用Socket API，通过TCP/IP协议栈发送或者接收。
3 应用层的协议
4 使用的是请求-应答通信模式，请求-应答模式也完全符合RPC（Remote Procedure Call）的工作模式，可以把HTTP请求处理封装成远程函数调用，导致了WebService、RESTful和gPRC等的出现。
5 无状态 TCP协议是有状态的，一开始处于CLOSED状态，连接成功后是ESTABLISHED状态，断开连接后是FIN-WAIT状态，最后又是CLOSED状态
6 明文传输，不安全
7 性能 队头阻塞
原文：https://www.cnblogs.com/autointerface/p/11940467.html