TCP/IP解析-优快云博客

tcp/ip协议族

tcp/ip是互联网相关的各种协议族总成。
tcp/ip各层及作用如下：

应用层
该层常见协议有http(超文本传输协议),dns(域名系统),ftp(文件传输协议)。
传输层
提供处于网络中的互联的两台计算机之间的数据传输。
在传输层有两个性质不同的协议，tcp(传输控制协议)和udp(用户数据包协议)。
网络层
网络层用来处理在网络中流动的数据包。数据包是网络传输最小数据单位。主要协议是ip
链路层
用来处理连接网络的硬件设备。举例：

首先作为发送端的客户端在应用层发送一个想看某个web页面的http请求
接着，为了传输便，在传输层(tcp协议)把从应用层收到的http请求报文进行分割，打上标记序列和端口号后发送给网络层
在网络层(ip协议)，增加作为通信目的地的mac地址后转发给链路层

tcp协议

面向连接
传输可靠（保证数据正确性）、有序（保证数据顺序）
传输大量数据（流模式）、速度慢、对系统资源的要求多，程序结构较复杂，
每一条TCP连接只能是点到点的， TCP首部开销20字节。

tcp三次握手

为了准确无误的将数据传输出去，tcp协议采用三次握手策略。发送端首先发送一个带有SYN标志的数据包给对方。接收端收到后，回传一个带有SYN/ACK标志的数据包以传达确认信息。最后，发送端再回传一个带有ACK标志的数据包，代表“握手”结束。

为什么需要三次握手而不是两次？

举例：已失效的连接请求报文段。
client发送了第一个连接的请求报文，但是由于网络不好，这个请求没有立即到达服务端，而是在某个网络节点中滞留了，直到某个时间才到达server，本来这已经是一个失效的报文，但是server端接收到这个请求报文后，还是会向client发出确认的报文，表示同意连接。

假如不采用三次握手，那么只要server发出确认，新的建立就连接了，但其实这个请求是失效的请求，client是不会理睬server的确认信息，也不会向服务端发送确认的请求，但是server认为新的连接已经建立起来了，并一直等待client发来数据，这样，server的很多资源就没白白浪费掉了，采用三次握手就是为了防止这种情况的发生，server会因为收不到确认的报文，就知道client并没有建立连接。这就是三次握手的作用。

tcp四次挥手

断开连接时，需要四次挥手。
第一次挥手
TCP发送一个FIN(结束)，用来关闭客户到服务端的连接。

客户端进程发出连接释放报文，并且停止发送数据。

第二次挥手

服务器收到连接释放报文，发出确认报文。TCP服务器知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。

第三次挥手

服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，此时，服务器就进入最后确认状态，等待客户端的确认。

第四次挥手

客户端发送ACK(确认)报文确认，并将确认的序号+1，这样关闭完成。

服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

思考：那么为什么是4次挥手呢？

为了确保数据能够完成传输。

关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。

udp协议

面向非连接
传输不可靠（可能丢包）、无序
传输少量数据（数据报模式）、速度快，对系统资源的要求少，程序结构较简单，
UDP支持一对一，一对多，多对一和多对多的交互通信，
UDP的首部开销小，只有8个字节。

编码提升传输速率

压缩传输的内容
分块传输
发送多种数据的多部分集合
获取部分内容
内容协商

http报文结构

用于http协议交互的信息成为http报文。客户端发送的成为请求报文，服务器端发送的为响应报文。http报文通常由报文首部和报文主体两部分组成。
报文首部由4部分组成：

请求行
包含用于请求的方法，请求URI和http版本
状态行
包含表明响应结果的状态码，原因短语和http版本
首部字段
包含各种条件和属性的首部字段
其他

状态码

1xx 接收的请求正在处理
2xx 请求正常完成。
200 ok 响应成功；204 想要成功但没有响应内容；206 响应成功只有部分内容
3xx 重定向
304 响应成功但内容已经在客户端的缓存中
4xx 客户端错误
400 语法错误；401 需要验证；403 禁止访问；404 找不到地址
5xx 服务器端错误
500 服务器错误

常用请求方法

get 获取资源
post 传输实体主体
head 获取报文首部
put 传输文件
delete 删除文件

常用首部字段

为缓存设置的字段
- Expires
- Cache-Control
- Last-Modified
为cookie服务的首部字段
- Set-Cookie
- Cookie
Accept-Charset
Accept-Language
Content-Type

http与https

HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全，为了保证这些隐私数据能加密传输，于是网景公司设计了SSL（Secure Sockets Layer）协议用于对HTTP协议传输的数据进行加密，从而就诞生了HTTPS。简单来说，HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全。

对称加密与非对称加密

对称加密使用共享密钥，发送方与接收方使用同一个密钥加密解密；
非对称加密使用公开密钥，发送方使用公钥加密，接收方使用私钥解密。

https四次握手

客户端请求建立SSL链接，并向服务端发送一个随机数–Client random和客户端支持的加密方法，比如RSA公钥加密，此时是明文传输。
服务端回复一种客户端支持的加密方法、一个随机数–Server random、授信的服务器证书和非对称加密的公钥。
客户端收到服务端的回复后利用服务端的公钥，加上新的随机数–Premaster secret 通过服务端下发的公钥及加密方法进行加密，发送给服务器。
服务端收到客户端的回复，利用已知的加解密方式进行解密，同时利用Client random、Server random和Premaster secret通过一定的算法生成HTTP链接数据传输的对称加密key – session key。

http1.0/http1.1/http 2.0

http1.0/http1.1

长连接
http1.0中，每有一次http请求就要断开一次tcp连接。如浏览器浏览一个包含多张图片的网页时，过程如下：(1)建立tcp连接-请求html网页-断开tcp连接;(2)建立tcp连接-请求图片-断开tcp连接；(3)建立tcp连接-请求图片-断开tcp连接；
http1.1中采用了长连接模式，只要任意一端没有提出断开连接,tcp连接将会一直建立。
节约带宽
HTTP 1.1支持只发送header信息(不带任何body信息)，如果服务器认为客户端有权限请求服务器，则返回100，否则返回401。客户端如果接受到100，才开始把请求body发送到服务器。这样当服务器返回401的时候，客户端就可以不用发送请求body了，节约了带宽。另外HTTP还支持传送内容的一部分。这样当客户端已经有一部分的资源后，只需要跟服务器请求另外的部分资源即可。这是支持文件断点续传的基础。
HOST域
现在可以web server例如tomat，设置虚拟站点是非常常见的，也即是说，web server上的多个虚拟站点可以共享同一个ip和端口。HTTP1.0是没有host域的，HTTP1.1才支持这个参数
保持状态 http1.0是无状态，http1.1引入cookie实现记录状态的功能。

http1.1/http2.0
多路复用
HTTP2.0使用了多路复用的技术，做到同一个连接并发处理多个请求，而且并发请求的数量比HTTP1.1大了好几个数量级。
数据压缩
HTTP1.1不支持header数据的压缩，HTTP2.0使用HPACK算法对header的数据进行压缩，这样数据体积小了，在网络上传输就会更快。