#tcp 三次握手四次挥手总体流程
TCP报文的结构
通过6个标志位(最主要的是SYN请求建立连接,ACK是确认标志位.FIN终止连接,此外还有URG表示紧急数据尽快发送,PSH是推送,要求接收方尽快交付给应用进程,RST复位标志代表TCP连接出错必须释放连接并重新建立连接)
***:发送方使用,根据发送的字节数据变化
确认序号:32位的确认号,是接收数据方期望收到方法的下一个报文段的序号,所以它会是上次以成功收到数据字节序号x+1.(下一次我希望收到的序号是x+1},那么对其的响应序号应该就是x+1)
窗口：用来控制对方发送的数据量，通知发送已确定的发送窗口上限（应该是告诉接收方我下一次只能接收多少数据吧）
校验和：该字段是校验数据有没有被修改的
序号：（1）seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。
（2）确认序号：ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，ack=seq+1。
（A）不要将确认序号ack与标志位中的ACK搞混了。
（B）确认方ack=发起方req+1，两端配对。
在第一次消息发送中，A随机选取一个***作为自己的初始序号发送给B；
第二次消息B使用ack对A的数据包进行确认，因为已经收到了***为x的数据包，准备接收***为x+1的包，所以ack=x+1，同时B告诉A自己的初始***，就是seq=y；
第三条消息A告诉B收到了B的确认消息并准备建立连接，A自己此条消息的***是x+1，所以seq=x+1，而ack=y+1是表示A正准备接收B***为y+1的数据包。
三次握手：涉及两个标志位：SYN（synchronize，用于请求建立连接）和ACK（acknowledge，用于确认）
第一次:
客户端发起请求(发送SYN1=1,ACK1=0)到服务器,此时,服务器进入’SYN_SENT’(客户端已经提交SYN报文)状态,等待服务器响应.
第二次:
服务器收到SYN包,确认客户端的SYN包而生成ACK(ACK=j+1)包,还有自己的一个请求编号SYN
(SYN=k), 即发送SYN+ACK包(发送SYN2=0,ACK2=1)到客户端.此时,服务器进入’SYN_RECV’状态.
第三次:
客户端收到服务器的SYN+ACK包,然后,自己向服务器发送确认包ACK(发送SYN1=0+1,ACK1=0+1=1),此时,服务器进入’ESTABLISHED’(链接成功)状态,完成三次握手
(连接完成状态表示为SYN1=1,ACK1=1,SYN2=1,ACK2=1).
为什么是三次握手而不是仅仅两次握手？
因为可能因为网络延迟等缘故，第一次握手时，在时间已经超时后客户端的syn才到服务器端；这个时候尽管客户端知道已经超时失效了，而服务器端还不知道，以为是刚刚发过来的，会回复一个ACK，统一建立连接。如果不采用三次握手，则此时服务器端发出确认后，连接就正式建立，但是因为客户端并没有发出建立连接的请求，也就不会回应服务器端的ACK，也不会向服务器端发数据。所以服务器端就会一直处于等待状态，浪费了大量的资源。
采用三次握手后，由于服务器向客户端发了SYN后得不到确认，就知道客户端并没有要求建立连接。
关于TCP时需要采用4次挥手。
过程和三次握手比较类似，就是在客户端第一次发关闭连接的FIN时，服务器端先发送ACK确认已经收到，然后等服务器自身完成之前所有报文发送后，再向客户端发送FIN，告知可以关闭了，最后客户端收到后再向服务器端发次一个ACK进行关闭
HTTP请求流程
其中ARP协议是将ip地址解析为物理地址(MAC地址)