网络体系
按照OSi模型划分
- 物理层
- 数据链路层
- 网络层
- 传输层
- 会话层
- 表示层
- 应用层
传输层：建立端到端的连接
如果利用谷歌和火狐同时访问一个网址，怎么服务器发送不同内容给不同的引用进程
浏览器会自动添加上端口号443，因为走的是https协议，电脑中会给谷歌和火狐分配不同的端口号，这样进行连接就像"管道"一样特定的进行传输
TCP
TCP报文里面有SYN，ACK和FIN等标识。如果设置1就是开启这些标识，如果设置0就是关闭这些标识。 SYN：Synchronization 同步 ACK：Acknowledgment 确认 FIN：Finish 结束
建立连接三次握手
首先假设主动发起请求的一端成为客服端，被动连接的一端称为服务端。不管是客服端还是服务端，TCP连接建立完成后都能发送和接受数据，所以TCP是一个全双工的协议。
起初，两端都为CLOSED状态，在通信开始前，双方都会创建TCB。服务器创建TCB后便进入LISTEN状态，此时开始等待客服端发送数据。
第一次握手
SYN 和 序号
客户端将同步号SYN设置为1，随机产生一个seq=x，将这个数据包发送给服务端。请求发送后，客服端进入SYN_SENT状态。
为什么需要通讯序号？因为应用程序可能连续发送多个序号给服务端，这样服务器就起码有依据判断哪些是累赘信息，而且Sequence序号是随机生成的，作为初始值来进行后续判断依据，这样就更加的保证了通道的唯一性。
第二次握手
服务端收到数据包后由同步号SYN=1知道客户端请求建立连接，服务端将标识位SYN和CK设置为1，ack=x+1，随机生成一个值seq=y，并将数据包发送给客户伏安已确认连接请求，服务端进入SYN_ECVD
第三次握手
客户端收到确认后，检查ack是否为x+1，ACK是否为1，如果正确则将标识为ACK置为1，ack=y+1，并将该数据包发送给服务端，服务端检查ack是否为y+1，ACK是否为1，如果正确则廉价建立成功，客户端和服务端进ESTABLISHED状态
为什么TCP建立简介需要三次握手，明明两次就可以建立连接了
因为这是为了防止出现失效的连接请求段被服务端接收的情况，从而产生错误。
可以想象如下场景。客服端发送了一个请求A，但是因为网络原因造成了超时，这是TCP回启动超时重传的机制再次发送一个连接请求B。此时请求顺利到达服务端，服务端应答完成建立了请求，然后接受数据后释放了连接。
假设这时连接请求A在两端关闭后终于到达了服务端，那么此时服务端回认为客服端又需要建立TCP连接，从而应答了请求并进入ESTABLISHED状态。但是客服端起时是CLOSED的状态，那么就会导致服务端一直等待，造成资源的浪费。
PS：在建立连接中，任意一端掉线，TCP都会重发SYN包，一般会重试五次，在建立连接中可能会遇到SYN Flood攻击，遇到这种情况我们可以选择降低重试次数或者干脆在不能处理的情况下拒绝请求
断开链接四次挥手
TCP是全双工的，在断开连接是两端都需要发送FIN和ACK。
第一次挥手
客服端发送FIN=1，和随机seq=u，用来关闭客户端到服务端的数据传送，将改数据包发送给服务端，客户端进入FIN_WAIT_1状态。
第二次挥手
服务端收到结束标志FIN=1后，发送确认标志ACK=1，确认号ack=u+1，随机产生一个seq=v，并将改数据包发送给客户端，服务端进入CLOSE_WAIT状态。
第三次挥手
服务端发送结束标志FIN=1，用来关闭服务端到客户端的数据传送，并发送确认标志ACK=1，随机产生一个seq=w，ack=u+1，并将数据包发送给客户端。服务端进入LAST_ACK状态。
PS：通过延迟确认的技术（通常有时间限制，否则对象回误认为需要重传），可以将第二次和第三次合并，延迟ACK包的发送。
第四次挥手
客户端收到FIN后，客户端进入TIME_WAIT状态，接着发送确认标志ACK=1给服务端，确认号seq=u+1，服务端进入CLOSED状态
为什么A进入TIME-WAIT状态，等待2MSL时间后才进入CLOSED状态
为了保证B能收到A的确认应答。若A发完确认后应到后直接进入CLOSED状态，如果确认应答因为网络问题一直没有到达，那么回造成B不能正常关闭。
