tcp

多点头发，少点代码 本文已经收录至我的GitHub,欢迎大家踊跃star 和 issues。 https://github.com/midou-tech/articles 本来想先更新TCP的基础和TCP可靠性等问题的，但是被你们暗示了，就先更流量控制和拥塞控制了。希望龙叔讲的你能搞清楚，如果有不清楚的，可以加龙叔微信一起探讨。 龙叔的号暂时还没开通留言功能(大家要是有留言号，可以贡献一个出来喔😆)，大家有什么问题就直接后台回复 龙叔 即可加龙叔微信，享受一对一技术探讨(只要是问我问题的都会回复大家，基本是在晚上十点之后和周末，做好不会秒回的心理准备) 流量控制 讲流量控制之前先花简短的话语絮叨下TCP基础知识，详细知识细节后面会出文章一一道来。 TCP是一种面向连接、保证可靠性、流式传输服务。 面向连接 就是建立链接，也就是面试常问的三次挥手建立链接，四次挥手断开链接。 保证可靠性 到是很好理解，就是你发送的数据尽最大可能保证让接收端接收到。 流式传输 就是传输的数据是以字节流的形式发送和接受(不要硬是和我说，什么字节流传输？明明物理层上都是波信号，这，抱拳。) TCP传输数据都是建立链接之后才进行传输，传输的时候为保证可靠性，也是采用确认应答机制。所谓确认应答机制就是发送数据之后必须收到确认消息，才算一次有效传输。 举个简单栗子，就是你和别人交流之前必须叫别人一声(这位先生你好

物联网开发对接 物联网设备 摄像头 读卡器 道闸 车牌识别 等等等等 通讯协议 框架选型 设备SDK 海康摄像头、车辆识别等设备 大华的摄像头 红门道闸 原理： 使用java的JNI或者JNA技术，调用c的驱动，实现设备数据的对接。 使用时注意区分部署平台 Linux下的驱动是so文件 ， windwos 下的驱动是 dll文件 JNI ： Java Native Interface JNA： Java Native Access netty-网络 ByteBuf对常见的字节操作做了封装 学习ByteBuf的文章 解决了TCP的粘包和拆包问题 什么是粘包和拆包？ 消息在网络中传播是乱序的，同时由于节省带宽，它会尽可能多在一次通讯中发送更多的数据。于是会出现这种情况。 举个例子： 南京市长江大桥(粘包) 出现了消息二义性，表达不清 一句话说一半 （拆包） 不知道后面的消息要表达啥？ 怎么解决呢？ 通过协议规范，约定对方消息的分隔符和长度等等。 对java的网络操作做了封装 Bootstrap Socket TCP客户端 ServerSocket TCP 服务端 DatagramSocket UDP jSerialComm-串口 针对java操作串口进行的封装 平台无关性 SerialPort gpsPort = SerialPort.getCommPort(device

` string ip = InitClass.ReadString("Jiguangji", "IP", ""); int port = 502; if (InitClass.ReadString("Jiguangji", "Port", "") != "") { port = Convert.ToInt32(InitClass.ReadString("Jiguangji", "Port", "")); } try { //1,创建socket Socket tcpClient = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp); //2,发起建立连接的请求 ** IPAddress ipaddress = IPAddress.Parse(ip); //可以把一个字符串的ip地址转化成一个ipaddress的对象** EndPoint point = new IPEndPoint(ipaddress, port); tcpClient.Connect(point); //通过ip：端口号 定位一个要连接到的服务器端 //发送模板给打印机` 来源： oschina 链接： https://my.oschina.net/xiaoxiezi/blog/3220682

oracle 配置服务端,类似我们配置java环境一样 防止乱码的配置: 变量名:NLS_LANG 变量值:SIMPLIFIED CHINESE_CHINA.ZHS16GBK 选择数据库的配置(重要): 变量值:TNS_ADMIN 变量名:D:\app\Administrator\product\11.2.0\dbhome_1\NETWORK\ADMIN(就是你的oracle安装的目录) 这是我的path配置: D:\app\Administrator\product\11.2.0\dbhome_1\bin;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%JAVA_HOME%\bin;%MAVEN_HOME%\bin;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\ oracle有两个文件特别重要 listener,和tnsnames,在D:\app\Administrator\product\11.2.0\dbhome_1\NETWORK\ADMIN文件夹下 修改后的文件: listener: # listener.ora Network Configuration File: D:\app\Administrator\product\11.2.0\dbhome

“ 在你生命的最初30年中，你养成习惯；在你生命的最后30年中，你的习惯决定了你。 ”---- Steve Jobs TCP/IP对于OSI参考模型的数据链路成及以下部分（物理层）没有做定义。但是，数据链路的知识对于深入理解网络起着至关重要的作用。 数据链路层的协议定义了通过 通信媒介 互联的设备之间的传输的规范。通信媒介包括双绞线电缆，光纤，电波等介质。 计算机以0和1表示信息，嗯安儿实际的通信媒介之间踔厉的是电压的高低，光的闪灭等信号，进行转换的正式物理层。数据链路层处理的数据也不是单纯的0 1序列，该层把它们集合为一个叫做帧的块，然后进行传输。 基本概念1： MAC地址： 网卡的地址，亦称为物理地址，任何一个网卡的mac地址都是全球唯一的，mac一般会烧入rom中。 另外，无线LAN，蓝牙设备中也使用同样规格的mac地址。 上图，各个主机都接收数据，然后各自根据数据头中的mac地址判断是不是给自己的数据。 基本概念2： 共享介质型网络： 多个设备使用同一个信道进行发送和接受，属于半双工通信（能接受 发送，但是不能同时进行）。为了协调各个设备对信道的使用，一般采用两种方式：争用方式 和 令牌传递方式 1）争用方式： 各个设备采用先到先得的方式占用信道发送数据，如果多个设备同时发送会产生冲突现象。 2）令牌传递方式：--- 不错的思想哈 沿着令牌环发送一种令牌报文

声明 本文转自 https://developer.51cto.com/art/201906/597963.htm 什么是RPC RPC（Remote Procedure Call）：远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的思想。 RPC 是一种技术思想而非一种规范或协议，常见 RPC 技术和框架有： 应用级的服务框架：阿里的 Dubbo/Dubbox、Google gRPC、Spring Boot/Spring Cloud。 远程通信协议：RMI、Socket、SOAP(HTTP XML)、REST(HTTP JSON)。 通信框架：MINA 和 Netty。 目前流行的开源 RPC 框架还是比较多的，有阿里巴巴的 Dubbo、Facebook 的 Thrift、Google 的 gRPC、Twitter 的 Finagle 等。 常用的RPC框架 gRPC：是 Google 公布的开源软件，基于最新的 HTTP 2.0 协议，并支持常见的众多编程语言。RPC 框架是基于 HTTP 协议实现的，底层使用到了 Netty 框架的支持。 Thrift：是 Facebook 的开源 RPC 框架，主要是一个跨语言的服务开发框架。 用户只要在其之上进行二次开发就行，应用对于底层的 RPC 通讯等都是透明的

1、简述osi七层模型和TCP/IP五层模型； 物理层 在OSI参考模型中，物理层（Physical Layer）是参考模型的最低层，也是OSI模型的第一层。 物理层的主要功能是：利用传输介质为数据链路层提供物理连接，实现比特流的透明传输。 物理层的作用是实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异。使其上面的数据链路层不必考虑网络的具体传输介质是什么。“透明传送比特流”表示经实际电路传送后的比特流没有发生变化，对传送的比特流来说，这个电路好像是看不见的。 数据链路层 数据链路层（Data Link Layer）是OSI模型的第二层，负责建立和管理节点间的链路。该层的主要功能是：通过各种控制协议，将有差错的物理信道变为无差错的、能可靠传输数据帧的数据链路。 在计算机网络中由于各种干扰的存在，物理链路是不可靠的。因此，这一层的主要功能是在物理层提供的比特流的基础上，通过差错控制、流量控制方法，使有差错的物理线路变为无差错的数据链路，即提供可靠的通过物理介质传输数据的方法。 该层通常又被分为介质访问控制（MAC）和逻辑链路控制（LLC）两个子层。 MAC子层的主要任务是解决共享型网络中多用户对信道竞争的问题，完成网络介质的访问控制； LLC子层的主要任务是建立和维护网络连接，执行差错校验、流量控制和链路控制。

原文来自： https://github.com/iMeiji/shadowsocks_install/wiki/%E5%BC%80%E5%90%AFTCP-BBR%E6%8B%A5%E5%A1%9E%E6%8E%A7%E5%88%B6%E7%AE%97%E6%B3%95 BBR 目的是要尽量跑满带宽, 并且尽量不要有排队的情况, 效果并不比速锐差 Linux kernel 4.9+ 已支持 tcp_bbr 下面简单讲述基于KVM架构VPS如何开启 附: OpenVZ 架构VPS开启BBR （容易导致判定滥用ban机，慎用！) Debian/Ubuntu TCP BBR 魔改版 (不支持4.13.*及更新的内核) Debian 8+ / Ubuntu 14 下载最新内核,最新内核查看 这里 wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.14.12/linux-image-4.14.12-041412-generic_4.14.12-041412.201801051649_amd64.deb 安装内核 dpkg -i linux-image-4.*.deb 删除旧内核(可选) dpkg -l | grep linux-image apt-get purge 旧内核 更新 grub 系统引导文件并重启 update-grub

无状态含义 每次的请求都是独立的，即不会受上一次请求状态的影响，也不会影响下一次的请求进程。如http 、udp 、ip均为无状态请求 有状态含义 与无状态请求相对应，上一次的请求成功与否直接影响下一次的请求进程。如tcp 为有状态请求 tcp 有状态请求过程 tcp的三次握手 1、当客户端开始发送请求建立连接时，客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认。 2、服务器收到syn包,必须确认客户的SYN（ack=j+1）,同时自己也发送一个SYN包（syn=k）,即SYN+ACK包,此时服务器进入SYN_RECV状态 3、客户端收到服务器的SYN＋ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手 SYN：同步序列编号(Synchronize Sequence Numbers) tcp的四次挥手 与tcp的三次握手建立连接对应，tcp的四次挥手就断开连接 1、客户端发送一个FIN，用来关闭客户端到服务器端的数据传送，客户端进入FIN_WAIT_1状态 2、服务器端收到FIN后，发送一个ACK给客户端，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），服务器端进入CLOSE_WAIT状态 3、服务器端发送一个FIN，用来关闭服务器端到客户端的数据传送