这张图好像挺有名的,其实一开始我看见的时候是一脸懵逼的,但是通过翻书(大学时代最害怕的计算机网络),查阅他人博客等等办法,最后终于有了一个系统的了解,当然,这里知识点多而杂,大家可以多看几遍,结合上面那张图,这张图实际上非常清楚,大家看完底下的内容再回来看这张图一定会恍然大悟.首先,大家先看这张图,要先从底下往上看,下面这个左边是绿色右边是红色的长方形实际上是一个数据包:IP首部:这个地方实际上是IP地址,是我们要发送到的机器的IP地址 IP数据部分:这个里面东西就非常多了,有目标IP地址的目标

TCP的三次握手是怎么进行的:发送端发送一个SYN=1,ACK=0标志的数据包给接收端,请求进行连接,这是第一次握手:接收端收到请求并且允许连接的话,就会发送一个SYN=1,ACK=1标志的数据包给发送端,告诉它,可以通讯了,并且让发送端发送一个确认数据包,这是第二次握手:最后,发送端发送一个SYN=0,ACK=1的数据包给接收端,告诉它连接已被确认,这就是第三次握手.之后,一个TCP连接建立,开始通讯.   *SYN:同步标志 同步序列编号(Synchronize Sequence Numbe

之前在<深入理解并行编程>的群里,有个小米的兄弟问了一个问题,服务器A发包给服务器B,Seq是1,但是在未能收到服务器B的报文回复的情况下,发送了rst,但是rst报文中,对应的seq是1461,一堆人都在猜测,为什么seq跳变了,由于当时只看到一半的图片,所以我让他发送完整报文出来之后,我 发现其实rst的seq不是1的原因,并不是因为跳变,而是正常的,因为发送给B的报文,长度为1460,但是这个报文没有得到回复,所以在超时之后,应用程序关闭了这条连接, 导致内核协议栈发送了一个rst报文,

调用返回报文标签中的存在中划线“-”,不符合规范,需要统一进行转换,但不能替换标签内的内容,利用正则匹配重新输出 /** * 正则匹配报文中的xml标签,将其中的"-"转换为"_",重新输出 * 示例<Card-No>120-111</Card-No> * 转换输出为:<Card_No>120-111</Card_No> */ public static String replaceMidLine(String res

今天在測试.net时,发现一个莫名其妙的问题:cookie老是保存不到浏览器端; 经过细致的比对成功与不成功的报文,居然无意中发现好像Date与它有关系,这太让我意想不到了,从来不知道cookie保存还要考虑报文中的date 而不是cookie的过期日期设置就可以,居然它的过期时间基点是date,而非浏览器边的客户机器时间优先? 关于报文的date时间是cookie过期时间起算点的验证代码例如以下,php的 header('Date: Mon, 17 Mar 2015 05:34:54 GMT'

第三章 HTTP报文中的HTTP信息 HTTP通信过程:客户端—>服务端,服务端—>客户端. 1.HTTP报文 使用HTTP协议交互的信息被称为HTTP报文,包括请求报文和响应报文. [请求报文和响应报文结构]报文首部(请求行/相应行+首部字段<请求.响应.通用.实体首部字段>)+报文主体  2.报文编码 HTTP在传输数据是可以通过编码技术来有效处理大量的访问请求,但会消耗更多的CPU等资源. [报文和实体]报文是箱子,是HTTP通信中的基本单位,由8位组字节流组成,通过HTTP

概述 在POST请求中,理论上请求端程序可以发送任意格式报文正文,但是最好在报文头Content-Type字段标明正文的格式,方便接收端根据Content-Type正确处理正文. 传统HTML-form表单提交 html-form表单中,post正文格式被定义在enctype属性中,该属性一共定义了3个值,分别对应Content-Type的3个值: enctype值 enctype描述 对应Content-Type的值 正文段格式示例 application/x-www-form-urlenco

HTTP状态码(status codes)是HTTP协议中,响应报文的起始行中包含的一种服务器用于向客户端说明操作状态的三位数字.例如在一个正常的GET请求完成后,服务器会向客户端返回 HTTP/ OK 在这个例子中,状态码就是 200 状态码的第一位数字表示了响应状态的类型,其中 1xx 信息提示 2xx 成功 3xx 重定向 4xx 客户端错误 5xx 服务器错误 今天我们主要讨论1xx的状态码,即消息状态码.由于当前的HTTP版本只为每种类型的状态码定义了少数一部分,而HTTP协议具有可拓

TCP .UDP .IP. ICMP协议报文格式分析 Tcp报文格式: Wireshark抓包如图: 源端口/目的端口(16bit): 在TCP报文中包涵了源端口/目的端口,源端口标识了发送进程,目的端口标识了接收方进程.由上图可以看出在此报文中我们的源端口号是54160, 目的端口是cichlid(1377). 序列号(32bit): Sequence Number这个是发送序列号,用来标识从源端向目的端发送的数据字节流,它表示在这个报文端中的第一个数据字节的顺序号,序列号是32位的无符号类型

前言 先说一下IP协议和TCP协议,IP协议是无连接的通信协议,IP不会占用两个设备之间通信的线路,IP实际上主要负责将每个数据包路由至目的地,但是IP协议并没有能够确保数据包是否到达,传过去的数据包是否按照顺序排列,所以IP数据包是不可靠的.而解决数据不可靠的问题就是由TCP协议来完成,接下来就介绍TCP协议,是如何让这些数据可靠的. TCP概念 TCP(Transmission Control Protocol 传输控制协议)是一种面向连接的.可靠的.基于字节流的传输层通信协议,前面的博客有

可能大家都听过TCP建立连接时需要经历三次握手和四次挥手的. 那么具体的握手挥手的过程是怎么样的呢? 这篇文章就通过WireShark抓包来了解TCP连接建立和断开的过程. 实验方法: 写一段简单的代码 代码客户端和服务端,分别部署,让客户端主动像服务器发起连接,随后断开.让WireShark抓股这个过程中产生了哪些包,并对其分析. (注:WireShark默认不支持LoopBack,需要将客户端和服务端分开部署,或是配置WireShark). 首先,我们先来看一下连接建立和断开的过程中,产生了

客户端与服务器之间数据的发送和返回的过程当中需要创建一个叫TCP connection的东西:由于TCP不存在连接的概念,只存在请求和响应,请求和响应都是数据包,它们之间都是经过由TCP创建的一个从客户端发起,服务器接收的类似连接的通道,这个连接可以一直保持,http请求是在这个连接的基础上发送的:在一个TCP连接上是可以发送多个http请求的,不同的版本这个模式不一样.在HTTP/1.0中这个TCP连接是在http请求创建的时候同步创建的,http请求发送到服务器端,服务器端响应了之后,这个T

计算机网络要点---TCP 浏览器在通过域名通过dns服务器找到你的服务器外网ip,将http请求发送到你的服务器,在tcp3次握手之后(http下面是tcp/ip),通过tcp协议开始传输数据,你的服务器得到请求后,开始提供服务,接收参数,之后返回你的应答给浏览器,浏览器再通过content-type来解析你返回的内容,呈现给用户.下面来说一下,TCP协议: 1.TCP协议 客户端与服务器之间数据的发送和返回的过程当中需要创建一个叫TCP connection的东西: 由于TCP不存在连接的概

1. TCP报文结构 TCP是一种可靠.面向连接.全双工的传输层协议,其报文格式如下所示:      源端口.目的端口:16位长.标识出远端和本地的端口号.     顺序号:32位长.表明了发送的数据报的顺序.     确认号:32位长.希望收到的下一个数据报的序列号.     TCP协议数据报头长度,因为TCP首部长度不固定.     头长:4位长.表明TCP头中包含多少个32位字.接下来的6位未用. ACK:ACK位置1表明确认号是合法的.如果ACK为0,那么数据报不包含确认信息,确认字段被

http://www.vckbase.com/index.php/wv/10http://blog.csdn.net/zlzlei/article/details/7689409 文章一: 当前在网络传输应用中,广泛采用的是TCP/IP通信协议及其标准的socket应用开发编程接口(API).TCP/IP传输层有两个并列的协议:TCP和UDP.其中TCP(transport control protocol,传输控制协议)是面向连接的,提供高可靠性服务.UDP(user datagram pro

[TCP协议](3)---TCP粘包黏包 有关TCP协议之前写过两篇博客: 1.[TCP协议](1)---TCP协议详解 2.[TCP协议](2)---TCP三次握手和四次挥手 一.TCP粘包.拆包图解 假设客户端分别发送了两个数据包D1和D2给服务端,由于服务端一次读取到字节数是不确定的,故可能存在以下四种情况: 1)服务端分两次读取到了两个独立的数据包,分别是D1和D2,没有粘包和拆包 2)服务端一次接受到了两个数据包,D1和D2粘合在一起,称之为TCP粘包 3)服务端分两次读取到了数据包,

入门 用户发了一个HTTP的请求,想要访问我们网站的首页,这个HTTP请求被放在一个TCP报文中,再被放到一个IP数据报中,最终的目的地就是我们的115.39.19.22. 进阶 IP数据报其实是通过数据链路层发过来的,使用ARP协议,把一个IP地址(115.39.19.22)给广播出去,然后具有此IP机器就会回复自己的MAC地址. 图解 图片来源"码农翻身"公众号

TCP应该是以太网协议族中被应用最为广泛的协议之中的一个,这里就聊一聊TCP协议中的TimeStamp选项.这个选项是由RFC 1323引入的,该C建议提交于1992年.到今天已经足足有20个年头.只是相信大部分程序员对这个建议还是相当陌生. 要理解为啥须要用TimeStamp选项.还须要从TCP协议的几个基本设计说起. TCP协议的几个设计初衷.以及引发的问题: 1. 协议规定收端不须要响应每个收到的数据报文,仅仅须要收到N个报文后,向发端回复一个ack报文就可以. 这种规定是为了提高通讯的效

一.简介 我们之前介绍过,TCP报文中的window size表示发出这个报文的一端准备多少bytes的数据,当TCP的一端一直接收数据,但是应用层没有及时读取的话,数据一直在TCP模块中缓存,最终受限于接收缓存的大小,window size会变为0,此时我们称呼这个接收窗口为零窗(zero window),对端也不能在发送更多的数据.如果随后本端应用层从TCP接收缓存中读取了足够数据,TCP模块有了足够的新的接收缓存的时候,就会发送一个TCP报文,并带有一个有效非零的Window size来指

一.Karn算法 在RTT采样测量过程中,如果一个数据包初传后,RTO超时重传,接着收到这个数据包的ACK报文,那么这个ACK报文是对应初传TCP报文还是对应重传TCP报文呢?这个问题就是retransmission ambiguity problem.当没有使用TSOPT选项,单纯的ACK报文并不会指示对应初传包还是重传包,因此就会发生这个问题. Karn算法指出,当RTO超时重传发生时候,我们不能依据这个TCP报文的ACK信息来更新RTT估计值.这是Karn算法的第一部分,如之前所说这个是R

  版权声明:本文为作者原创文章,可以随意转载,但必须在明确位置表明出处!!! 之前有一篇文章介绍了http协议「初识http协议」, http协议协议是基于tcp协议的,所以作者觉得有必要针对tcp协议做一个介绍,希望各位读者能够静下心来认真阅读,也可以自己去看看TCP/IP协议详解这本书,一定要让自己成为那20%的人. TCP(Transmission Control Protocol 传输控制协议)是一种面向连接的.可靠的.基于字节流的传输层通信协议,对TCP协议的文章网上已经很成熟了,今