大家好，欢迎来到IT知识分享网。
一、网络协议
二、TCP（Transmission Control Protocol，传输控制协议）
1、TCP头格式
备注：ISN（Inital Sequence Number）：初始化Sequence Number，发生在建立连接时。
2、TCP协议中的三次握手和四次挥手
三次握手可以理解成：
我打电话给你你没看到，一会之后你又打电话给我问有什么事，我再给你说我有什么什么事
四次挥手可以理解成：
我给你说我不想再要你送的东西了，你说不行啊还有很多没有送完（继续在送），（送完啦）你说已经把所有东西都送给我啦，我说我收到了那就结束吧———–
特别注意
建立连接需要三次握手
第一次握手：客户端向服务端发送连接请求包，标志位SYN（同步序号）值为1，顺序号码为X=0。
第二次握手：服务端收到客户端发过来报文，由SYN=1知道客户端要求建立联机，则为这次连接分配资源。并向客户端发送一个SYN和ACK都置为1的TCP报文，设置初始顺序号码Y=0，将确认序号(ack)设置为上一次客户端发送过来的顺序号(Seq)加1，即X+1 = 0+1=1。
第三次握手：客户端收到服务端发来的包后检查确认号码(ack)是否正确，即第一次发送的Seq加1（X+1=1）。以及标志位ACK是否为1。若正确，服务端再次发送确认包，ACK标志位为1，SYN标志位为0。确认号码(ack)=Y+1=0+1=1，发送顺序号码(Seq)为X+1=1。Server收到后确认号码值与ACK=1则连接建立成功，可以传送数据了。
断开连接需要四次挥手
第二次挥手：服务端收到FIN后，发回一个ACK(标志位ACK=1),确认号码为收到的顺序号码加1，即X=X+1=2。顺序号码为收到的确认号码=Z。意思是说“你的FIN请求我收到了，但是我还没准备好，请继续你等我的消息” 这个时候客户端就进入FIN_WAIT状态，继续等待服务端的FIN报文。
第三次挥手：当服务端确定数据已发送完成，则向客户端发送FIN报文，关闭与客户端的连接。标志位FIN和ACK值为1，顺序号码为Y=1，确认号码为X=2。意思是告诉Client端“好了，我这边数据发完了，准备好关闭连接了。”
第四次挥手：客户端收到服务器发送的FIN之后，发回ACK确认(标志位ACK=1),确认号码为收到的顺序号码加1，即Y+1=2。顺序号码为收到的确认号码X=2。意思是“我Client端知道可以关闭连接了，但是我还是不相信网络，怕 Server端不知道要关闭，所以发送ACK后进入TIME_WAIT状态，如果Server端没有收到ACK则可以重传。Client端等待了2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，我Client端也可以关闭连接了。“（在TIME_WAIT状态中，如果TCP client端最后一次发送的ACK丢失了，它将重新发送。TIME_WAIT状态中所需要的时间是依赖于实现方法的。典型的值为30秒、1分钟和2分钟。等待之后连接正式关闭，并且所有的资源(包括端口号)都被释放。）
3、TCP报文抓取工具：Wireshark
三、HTTP（HyperText Transfer Protocol，超文本传输协议）
另外，HTTP请求报文和响应报文都是由开始行（对于请求消息，开始行就是请求行，对于响应消息，开始行就是状态行），消息报头（可选），空行（只有CRLF的行），消息正文（可选）组成。将在下面详细讲解。
1、请求报文结构
报文中的数据都使用ASCII编码，各个字段的长度是不确定的（除了作为结尾的CRLF外，不允许出现单独的CR或LF字符）。
2、请求报文样例
POST /search HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-silverlight, application/x-shockwave-flash, */* Referer: http://www.google.cn/ Accept-Language: zh-cn Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; TheWorld) Host: www.google.cn Connection: Keep-Alive Cookie: PREF=ID=80a06da87be9ae3c:U=fe2c3b714:NW=1:TM=:LM=:S=ybYcq2wpfefs4V9g; NID=31=ojj8d-IygaEtSxLgaJmqSjVhCspkviJrB6omjamNrSm8lZhKy_yMfO2M4QMRKcH1g0iQv9u-2hfBW7bUFwVh7pGaRUb0RnHcJU37y- FxlRugatx63JLv7CWMD6UB_O_r hl=zh-CN&source=hp&q=domety 3、请求报文参数详解
请求方法
所有请求方法名称全为大写，目前有9种：
请求报头域
报头域指头部中的Key，且不分大小写。
4、响应报文结构
如所见，响应报文结构与请求报文结构唯一真正的区别在于第一行中用状态信息代替了请求信息。状态行（status line）通过提供一个状态码来说明所请求的资源情况。
5、响应报文样例
HTTP/1.1 200 OKDate: Mon, 23 May 2005 22:38:34 GMTContent-Type: text/html; charset=UTF-8Content-Encoding: UTF-8Content-Length: 138Last-Modified: Wed, 08 Jan 2003 23:11:55 GMTServer: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)ETag: "3f80f-1b6-3e1cb03b"Accept-Ranges: bytesConnection: close<html><head> <title>An Example Page</title></head><body> Hello World, this is a very simple HTML document.</body></html>6、响应报文参数详解
响应状态码
其它状态码请查阅：
https://en.wikipedia.org/wiki/List_of_HTTP_status_codes
响应报头域
报头域指头部中的Key，且不分大小写。
7、HTTP报文抓取工具
8、Session和Cookie
说到HTTP，就不得不提Session和Cookie。但严格来说，Session和Cookie并不是http协议的一部分。由于HTTP协议设计原则是无状态的，但是近年来出现了种种需求，其中cookie的作用就是为了解决HTTP协议无状态的缺陷所作出的努力。后来出现的session机制则是又一种在客户端与服务器之间保持状态的解决方案。 具体来说cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。同时我们也看到，由于采用服务器端保持状态的方案在客户端也需要保存一个标识，所以session机制可能需要借助于cookie机制来达到保存标识的目的，但实际上它还有其他选择。
Session
Cookie
保存SessionID的方式可以采用Cookie，这样在交互过程中浏览器可以自动的按照规则把这个SessionID发回给服务器。Cookie的命名方式类似于SessionID。有时Cookie被人为的禁止，所以出现了其他机制以便在Cookie被禁止时仍然能够把SessionID传递回服务器。这种技术叫做URL重写，就是把SessionID直接附加在URL路径的后面，附加方式也有两种，一种是作为URL路径的附加信息，表现形式为
http://www.wantsoft.com/index.asp;jsessionid=
ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!- 。
另一种是作为查询字符串附加在URL后面，表现形式为
http://www.wantsoft.com/index?js … 99zWpBng!- 。
免责声明：本站所有文章内容,图片，视频等均是来源于用户投稿和互联网及文摘转载整编而成，不代表本站观点，不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益，请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权，请联系删除，如若转载，请注明出处：https://haidsoft.com/182405.html
