序列号

为何TCP采用随机序列号 TCP采用随机序列号，主要是基于如下两个原因： 防止接受网络上粘滞的TCP包，如果都从0开始的话，极其容易接受之前断开连接发送的 粘滞包 。虽然可以采用每次TCP会话都使用一个UUID作为标记，但是考虑到每次都要携带UUID，比较浪费流量，所以就采用随机序列号的方法。 防止Hack猜测序列号，然后伪装TCP报文，当然这种防御其实很弱。 TCP总的来说，提供了一种可靠的流数据传输方式，但是还是有各种坑。比如说，超时检测，粘包，安全性等问题。 在一定程度上，可以把TCP连接，看成能保证从FIRST_ACK到LAST_ACK的流协议 来源： oschina 链接： https://my.oschina.net/u/1999248/blog/620885

餐前小菜 我买的 Arduino 是入门套件 + RFID学习套件，某宝包邮130+，买来也将近1个月了。 有的店铺需要确认收货后去向客服索取配套资料的链接。其实网上的资料都大致一样，有的卖家只是修改了文件的名字，有的甚至修改了代码却没有保留最初的源代码，真是可恶。资料不能公开分享就算了，还把源码给改了。 今天我还是试了4位数码管的实验，发现给的资料和代码跟发的数码管不是一个型号，以至于显示一堆乱码。卖家发的数码管是 3461BS （0.36英寸 4位LED数码管 共阳极）。不得不自己到网上找的原理图并修改代码。下边分享给大家： 四位共阳极数码管，位控制端(1-4)给高电平使能相应的位，笔段控制端(A-G、DP)给低电平可点亮。 记得要加限流电阻哦！ 数码管的原理图我还是看的懂的。我所异者，是做一天和尚敲一天钟，不思进取，敷衍了事，不愿追求把工作做到极致的态度。 实验由来 2015年12月04日（周五） 上午 博士的智能卡实验——RFID识别实验，基于51单片机； 我们的实验用的读写器是 RFID-RC522 模块，刚好和我买的 Arduino RFID 套件里的是同一款； 实验时候并没有完成，因为在烧写程序的时候一直烧不进去，好吧，下午在办公室的时候我们博士说有一块单片机是有问题的， TMD有那么巧吗 中午开始我就开始阅读 Arduino 套件配套的 RFID 实验资料

TCP的概述 TCP把连接作为最基本的对象，每一条TCP连接都有两个端点，这种断点我们叫作套接字（socket），它的定义为端口号拼接到IP地址即构成了套接字，例如，若IP地址为192.3.4.16 而端口号为80，那么得到的套接字为192.3.4.16:80。 TCP报文首部 源端口和目的端口，各占2个字节，分别写入源端口和目的端口； 序号，占4个字节， TCP连接中传送的字节流中的每个字节都按顺序编号 。例如，一段报文的序号字段值是 301 ，而携带的数据共有100字段，显然下一个报文段（如果还有的话）的数据序号应该从401开始； 确认号，占4个字节，是 期望收到对方下一个报文的第一个数据字节的序号 。例如，B收到了A发送过来的报文，其序列号字段是501，而数据长度是200字节，这 表明B正确的收到了A发送的到序号700为止的数据 。因此，B期望收到A的下一个数据序号是701，于是B在发送给A的确认报文段中把确认号置为701； 数据偏移，占4位，它指出TCP报文的数据距离TCP报文段的起始处有多远； 保留，占6位，保留今后使用，但目前应都位0； 紧急URG，当URG=1，表明紧急指针字段有效。告诉系统此报文段中有紧急数据； 确认ACK，仅当ACK=1时，确认号字段才有效。TCP规定，在连接建立后所有报文的传输都必须把ACK置1； 推送PSH，当两个应用进程进行交互式通信时

相同点 UDP协议和TCP协议都是传输层协议。 TCP（Transmission Control Protocol，传输控制协议）提供的是面向连接，可靠的字节流服务。即客户和服务器交换数据前，必须现在双方之间建立一个TCP连接，之后才能传输数据。并且提供超时重发，丢弃重复数据，检验数据，流量控制等功能，保证数据能从一端传到另一端。 UDP（User Data Protocol，用户数据报协议）是一个简单的面向数据报的运输层协议。它不提供可靠性，只是把应用程序传给IP层的数据报发送出去，但是不能保证它们能到达目的地。由于UDP在传输数据报前不用再客户和服务器之间建立一个连接，且没有超时重发等机制，所以传输速度很快。 不同点 报头不同 特点不同 协议不同 UDP 报头 UDP数据报最大长度64K（包含UDP首部），如果数据长度超过64K就需要在应用层手动分包，UDP无法保证包序，需要在应用层进行编号。 特点 无连接 ：知道对端的IP和端口号就直接进行传输, 不需要建立连接。 不可靠 ：没有确认机制, 没有重传机制; 如果因为网络故障该段无法发到对方, UDP协议层也不会给应用层返回任何错误信息。 面向数据报 ：不能够灵活的控制读写数据的次数和数量，应用层交给UDP多长的报文, UDP原样发送, 既不会拆分, 也不会合并。 数据收不够灵活，但是能够明确区分两个数据包，避免粘包问题。 协议

一.数据控制语句 (DML) 部分 　　1.INSERT 　　(往数据表里插入记录的语句) 　　INSERT INTO 表名(字段名1, 字段名2, ……) VALUES ( 值1, 值2, ……); 　　INSERT INTO 表名(字段名1, 字段名2, ……) 　　SELECT 字段名1, 字段名2, …… FROM 另外的表名; 　　字符串类型的字段值必须用单引号括起来, 例如: ’GOOD DAY’ 　　如果字段值里包含单引号’ 需要进行字符串转换, 我们把它替换成两个单引号''. 　　字符串类型的字段值超过定义的长度会出错, 最好在插入前进行长度校验. 　　日期字段的字段值可以用当前数据库的系统时间SYSDATE, 精确到秒 　　或者用字符串转换成日期型函数TO_DATE(‘2001-08-01’,’YYYY-MM-DD’) 　　TO_DATE()还有很多种日期格式, 可以参看ORACLE DOC. 　　年-月-日 小时:分钟:秒 的格式YYYY-MM-DD HH24:MI:SS 　　INSERT时最大可操作的字符串长度小于等于4000个单字节, 如果要插入更长的字符串, 请考虑字段用CLOB类型, 　　方法借用ORACLE里自带的DBMS_LOB程序包. 　　INSERT时如果要用到从1开始自动增长的序列号, 应该先建立一个序列号 　　CREATE SEQUENCE

openssl系列文章： http://www.cnblogs.com/f-ck-need-u/p/7048359.html 主要用于输出证书信息，也能够签署证书请求文件、自签署、转换证书格式等。 openssl x509工具 不会使用openssl配置文件中的设定，而是完全需要自行设定或者使用该伪命令的默认值，它就像是一个完整的小型的CA工具箱 。 openssl x509 [-in filename] [-out filename] [-serial] [-hash] [-subject_hash] [-issuer_hash] [-subject] [-issuer] [-nameopt option] [-email] [-startdate] [-enddate] [-purpose] [-dates] [-modulus] [-pubkey] [-fingerprint] [-noout] [-days arg] [-set_serial n] [-signkey filename] [-x509toreq] [-req] [-CA filename] [-CAkey filename] [-CAcreateserial] [-CAserial filename] [-text] [-md2|-md5|-sha1|-mdc2] [-extfile filename] [

序列化和反序列化的概述 序列化就是把对象存储到文件中。 要想实现对象的序列化 ，这个类必须要实现serializable接口（充当一个标记作用） 有了这个标记，在序列化时，系统会自动分配一个序列号（用作校对序列前后，也可手动指定） 对象序列化流 ObjectOutPutStream （对象输出流） 和 ObjectInputStream （对象输入流） ObjectOutPutStream （对象输出流） ObjectOutPutStream 继承自 OutPutStream类 它特有的方法： writerObject() 调用此方法 将对象写入到文件中 // 使用步骤 /*1、先创建一个ObjectOutputStream对象，构造方法传入一个FileOutputStream（指定序列化后输出地址） 2、调用特有方法 wirterObject 方法 写入文件 3、释放资源 */ ObjectOutputStream oos = new ObjectOutputStream ( new FileOutputStream （“c : \\abc . txt”） ) ; oos . writerObject ( new student ( "xiaoming" , 12 ) ) ; // 写入一个自定义对象 student oos . close ( ) ; //3、释放资源

1.校验和机制 TCP检验和的计算与UDP一样，检验范围包括TCP首部及数据部分,但是UDP的检验和字段为可选的，而TCP中是必须有的。计算方法为:在发送方将整个报文 段分为多个16位的段，然后将所有段进行反码相加，将结果存放在检验和字段中，接收方用相同的方法进行计算，如最终结果为检验字段所有位是全1则正确(UDP中为0是正确)，否则存在错误。 2.确认应答与序列号 TCP将每个字节的数据都进行了编号,这就是序列号。 序列号的作用: a、保证可靠性(当接收到的数据少了某个号的数据时，能马上知道) b、保证数据的按序到达 c、提高效率，可实现多次发送，一次确认 d、去除重复数据 数据传输过程中的确认应答处理、重发控制以及重复控制等功能都可以通过序列号来实现。 TCP通过确认应答机制实现可靠的数据传输。在TCP的首部中有一个标志位——ACK，此标志位表示确认号是否有效。接收方对于按序到达的数据会进行确认，当标志位ACK=1时，确认字段有效。进行确认时，确认字段值表示这个值之前的数据都已经按序到达了。而发送方如果收到了已发送的数据的确认报文，则继续传输下一部分数据；而如果等待了一定时间还没有收到确认报文就会启动重传机制。 3. 超时重传 当报文发出后在一定的时间内未收到接收方的确认，发送方就会进行重传（通常是在发出报文段后设定一个闹钟，到点了还没有收到应答则进行重传）。

一、TCP协议简介 TCP，全称Transfer Control Protocol，中文名为传输控制协议，它工作在OSI的传输层，提供面向连接的可靠传输服务。是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC 793 [1] 定义。 TCP的工作主要是建立连接，然后从应用层程序中接收数据并进行传输。TCP采用虚电路连接方式进行工作，在发送数据前它需要在发送方和接收方建立一个连接，数据在发送出去后，发送方会等待接收方给出一个确认性的应答，否则发送方将认为此数据丢失，并重新发送此数据。 工 作：与IP协议共同使用 下面我们来介绍一下TCP的报头结构和相关工作原理： TCP报头 TCP报头总长最小为20个字节，其报头结构如下图（图1）所示； 源端口：指定了发送端的端口 目的端口：指定了接受端的端口号 序号：指明了段在即将传输的段序列中的位置 确认号：规定成功收到段的序列号，确认序号包含发送确认的一端所期望收到的下一个序号 TCP偏移量：指定了段头的长度。段头的长度取决与段头选项字段中设置的选项 保留：指定了一个保留字段，以备将来使用 标志：SYN、ACK、PSH、RST、URG、FIN SYN： 表示同步 ACK： 表示确认 PSH： 表示尽快的将数据送往接收进程 RST： 表示复位连接 URG： 表示紧急指针 FIN： 表示发送方完成数据发送 窗口

转自：http://blog.163.com/liu_nongfu/blog/static/19079414220139169225333/ 一、流媒体简介 　　流媒体是指在internet中使用流媒体技术的连续时基媒体，例如视频、音频或多媒体文件。流式传输方式是将音视频、动画等多媒体文件经过压缩后分成一个个小数据包，当用户端发出请求时，由服务器端向用户端实时、连续传送这些小数据包，动态变化的网络可能使各个包选择不同的路由，故到达用户端的时间延迟也就不同。在用户端用播放器播放时，需要为接收数据开辟缓存区，以弥补时延和时延抖动的影响和保证数据包传输顺序的正确，经解压缩后，只需要在缓冲区充满前等待几秒钟，就可以连续观看。而同时，后续数据包继续在后台从服务器端以稳定的速率向客户端发送，不影响前台播放。所以从理论上讲，播放前的延时主要是由于播放器接收、处理前几个数据包引起的，一旦播放就能够保证连续性和稳定性。流式传输的实现不仅需要高效的压缩算法和缓存，而且需要合适的传输协议。由于tcp需要较多的开销，不太适合传输实时数据。在流式传输的实现方案中，一般采用http/tcp来传输控制信息，而用RTP/UDP来传输实时视音频数据。实现流式传输一般都需要专用的媒体服务器和媒体播放器。 二、流媒体传输的网络协议：RTP与RTCP介绍 1.实时传输协议RTP( Real-time Transport