网络端口

第一次握手：建立连接时，客户端发送syn包（syn=x）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。 第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态； 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=y+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。 第一次握手：建立连接时，客户端发送syn包（syn=x）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。 第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态； 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=y+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。 所有执行主动关闭的socket都会进入TIME_WAIT状态 ， 主动关闭的一方在发送最后一个

本文首发于 vivo互联网技术 微信公众号 链接： https://mp.weixin.qq.com/s/gk-Hb84Dt7JqBRVkMqM7Eg 作者：张文博 领域驱动设计（Domain Driven Design，DDD）其实并非新理论，大家可以看看 Eric Evans 编著的《领域驱动设计》原稿首版是2003年，距今已十余年时间。与现在的分布式、微服务相比，绝对是即将步入中年的“老家伙”了。 直到近些年微服务理论被提出、被互联网行业广泛使用，人们似乎又重新发现了领域驱动设计的价值。所以看起来也确实是因为微服务，领域驱动设计才迎来了第二春。 不过我发现大家对DDD也存有一些误区，使其渐渐成了一门“高深的玄学”，随之又被大家束之高阁。我本人在过去两年多的时间里，研读过多本DDD相关的经典论著、也请教过一些资深DDDer，并在项目中实践过。 不过在初步学习、实践之后我又带着疑问与自己的思考重新读了一遍相关的著述理论。逐渐领悟到DDD作为一种思想，其实离我们很近。 我把自己的学习过程、思考编写成系列文章，与大家一起探讨学习，希望大家能够有所收获，当然其中不正确的地方也欢迎大家批评指正。 同时，在文章中我也会引用相关的论著或者一些我认为不错的案例素材，权当是我们对这些知识的详细诠释，在这里一并对这些DDD前辈的不倦探索表示感谢。 （DDD相关的经典论著） 一、关于DDD的误区

本文主要谈谈关于主机网络和容器网络的实现原理！ 容器资源限制 在某些时候我们不想让容器肆无忌惮的抢占系统资源，所以就会对其做一系列的限制，这些参数可以使用蛮力查看到： docker container run --help 主要的限制参数包含以下这些： --cpu-shares ：CPU 使用占比，如一个容器配置 10，一个配置 20，另外一个配置 10，那就是资源分配：1:2:1。 --memory ：限制内存，比如配置 200M，但是如果不配置 swap，则实际内存其实是 400M。 --memory-swap ：限制 swap，结合内存限制使用。 虚拟机网络名称空间（选择性了解） docker 网络隔离的实现方式其实就是网络名称空间的方式，但是这方面的知识其实对于就算是运维工程师也不一定有详细的了解，所以这部分内容作为选择性了解。简单的对其实现方式说明，然后看看效果是怎样的。 1. 建立两个网络名称空间： # 查看现有的网络名称空间 ip netns ls # 新建两个网络名称空间 ip netns add net-ns-1 ip netns add net-ns-2 # 在两个网络名称空间中分别查看它的网卡信息 ip netns exec net-ns-1 ip a ip netns exec net-ns-2 ip a 结果如图： 可以看到各自拥有一张回环网卡，并且未启动

第五章 传输层 ->传输层协议UDP和TCP ->网络安全 ->TCP可靠传输的实现 ->TCP的流量控制 ->TCP的拥塞控制 ->TCP的运输连接管理 5.1 OSI和DoD模型 下图必须背下来。尤其是传输层和网络层的协议。 传输层最大数据包是65535字节，而网络层数据最大只有1480字节。所以需要分段，但是只要分段，就有可能丢包，因为网络层不负责可靠传输。所以要求服务器和客户端保持会话，直到数据传输完成。 ->TCP(Transmission Control Protocol)传输控制协议 应用场景：需要将要传输的文件分段传输时；就需要TCP协议来建立会话实现可靠传输；同时也有流量控制功能。(例如QQ传文件) 查看会话 netstat -n 查看建立会话的进程 netstat -nb ->UDP(User Data Protocol)用户数据报协议 应用场景：一个数据包就能完成数据通信；不需要建立会话和流量控制；多播/广播；是一种不可靠传输。(例如QQ聊天，屏幕广播) 5.2 传输层协议和应用层协议的关系 (1)TCP和UDP协议和不同的端口即可对应一个应用层的协议。注意，53大部分是与UDP相连。 (2)熟知数值一般为0-1023，登记端口号数值1024-49151，客户端口号数值为49152-65535. (3)常用的应用层协议使用的端口(号)： http = TCP

最早出现的网络驱动应该是网卡驱动，这是Windows的下进行网络安全攻防常见的需求，为了进一步分割应用程序的网络数据传输与下层协议直到下层硬件的关系，又出现了协议驱动，后来微软和硬件商联合制定了NDIS标准，作为从硬件到协议的内核驱动程序的调用接口标准，而协议驱动与应用层的API之间，则出现了TDI接口，即从上到下的关系是 应用层API -> TDI -> 协议驱动 -> NDIS -> 下层硬件 Windows NT支持三种类型的驱动： 自上而下的关系为： 网络接口卡驱动（NIC） NIC驱动管理网络接口卡（NIC）。NIC驱动接口在下边界直接控制硬件（NIC），在上边界提供上层驱动访问的接口： 发送和接收包 重置NIC（Reset） 停止NIC 查询NIC 设置NIC操作特性 NIC驱动的两种类型 微端口驱动：微端口驱动应用于管理NIC硬件特殊操作，包括在NIC上发送和接收数据。微端口驱动不能直接呼叫系统例程，只能呼叫NDIS提供的函数。 完全NIC驱动：完全NIC驱动不仅管理硬件而且管理NDIS完成的的操作系统特定任务。完全NIC驱动必须保持接收数据的绑定信息。 中间协议驱动 中间协议驱动是指位于上层协议驱动和微端口驱动之间的接口。 中间协议驱动接口位于上层协议驱动和微端口驱动之间。对于上层传输驱动程序来说，中间驱动看起来像是微端口驱动。对微端口驱动来说，看起来像是协议驱动

近期我们公司的服务器的是某港那边的总是出现ssh连接自动端口和连接不上，网上一查说是”网络抖动“，嗯？？ 我想着换个远程连接端口试一试，说做就做 步骤： 第一步：修改配置文件。 [root@izj6c5kizjjj1wdi4asd ~]# vim /etc/ssh/sshd_config #Port 22 Port 39123 #此处添加一个随机算口，注意要系统之前没有被占用的，最好是1000以后的端口 #ListenAddress 0.0.0.0 #ListenAddress :: [root@izj6c5kizjjj1wdi4asd ~]# systemctl restart sshd 第二步：查看端口是否备监听 [root@izj6c5kizjjj1wdi4asd ~]# netstat -tanpl|grep 39123 tcp 0 0 0.0.0.0:39123 0.0.0.0:* LISTEN 19632/sshd tcp 0 52 XXX.XXX.XXX.XXX:39123 220.248.XXX.XXX:56533 ESTABLISHED 21089/sshd: root@pt 第三步：打开阿里云安全组，开放此端口 比如如下规则： 第四步：开始测试连接性 连接成功 说明换端口成功，这样原来的22号端口就没法连接 总结：其实就是改下sshd

Nmap参数汇总 之前写了几遍关于nmap的文章，虽然是写的很多参数，但是平常去查的时候不方便，今天做个整合 （可能不是很全，有错误的话可以告诉我哈） 主机发现 nmap -sn [ target ] 只进行主机发现，不扫描端口和其他信息 nmap -PR [ target ] 使用ARP协议进行主机发现适用于同一网段的目标 nmap -sn -PE [ target ] 通过ICMP协议进行主机发现，相当于ping nmap -sn -PP [ target ] 通过ICMP协议的时间戳进行主机发现 nmap -sn -PM [ target ] 通过ICMP协议的地址掩码进行主机发现 nmap -sn -PS [ target ] TCP SYN扫描 nmap -sn -PA [ target ] TCP ACK扫描 nmap -sn -PU [ target ] 使用UDP协议进行主机发现 nmap -sn -PY [ target ] 使用SCTP协议进行主机发现 nmap -sn -PO [ target ] 使用IP协议进行主机发现 nmap -R [ target ] 反向域名解析 nmap -n [ target ] 取消域名解析 nmap --dns-servers [ server1...] [ target ] 使用指定的dns服务器来查询目标 -

本文首发于 vivo互联网技术 微信公众号 链接： https://mp.weixin.qq.com/s/gk-Hb84Dt7JqBRVkMqM7Eg 作者：张文博 领域驱动设计（Domain Driven Design，DDD）其实并非新理论，大家可以看看 Eric Evans 编著的《领域驱动设计》原稿首版是2003年，距今已十余年时间。与现在的分布式、微服务相比，绝对是即将步入中年的“老家伙”了。 直到近些年微服务理论被提出、被互联网行业广泛使用，人们似乎又重新发现了领域驱动设计的价值。所以看起来也确实是因为微服务，领域驱动设计才迎来了第二春。 不过我发现大家对DDD也存有一些误区，使其渐渐成了一门“高深的玄学”，随之又被大家束之高阁。我本人在过去两年多的时间里，研读过多本DDD相关的经典论著、也请教过一些资深DDDer，并在项目中实践过。 不过在初步学习、实践之后我又带着疑问与自己的思考重新读了一遍相关的著述理论。逐渐领悟到DDD作为一种思想，其实离我们很近。 我把自己的学习过程、思考编写成系列文章，与大家一起探讨学习，希望大家能够有所收获，当然其中不正确的地方也欢迎大家批评指正。 同时，在文章中我也会引用相关的论著或者一些我认为不错的案例素材，权当是我们对这些知识的详细诠释，在这里一并对这些DDD前辈的不倦探索表示感谢。 （DDD相关的经典论著） 一、关于DDD的误区

kube-APIserver组件介绍 kube-APIserver提供了k8s各类资源对象（pod,RC,Service等）的增删改查及watch等HTTP Rest接口，是整个系统的数据总线和数据中心。 kube-APIserver的功能 提供了集群管理的REST API接口(包括认证授权、数据校验以及集群状态变更) 提供其他模块之间的数据交互和通信的枢纽（其他模块通过API Server查询或修改数据，只有API Server才直接操作etcd） 是资源配额控制的入口 拥有完备的集群安全机制 kube-apiserver工作原理图 kubernetes API的访问 k8s通过kube-apiserver这个进程提供服务，该进程运行在单个k8s-master节点上。默认有两个端口 本地端口 该端口用于接收HTTP请求 该端口默认值为8080，可以通过API Server的启动参数“--insecure-port”的值来修改默认值 默认的IP地址为“localhost”，可以通过启动参数“--insecure-bind-address”的值来修改该IP地址 非认证或授权的HTTP请求通过该端口访问API Server 安全端口 该端口默认值为6443，可通过启动参数“--secure-port”的值来修改默认值 默认IP地址为非本地（Non-Localhost）网络端口

编辑 随着Internet的 发展 ， 局域网 和 广域网技术 得到了广泛的推广和应用。 数据交换技术 从简单的电路交换发展到二层交换，从二层交换又逐渐发展到今天较成熟的三层交换，以致 发展 到将来的高层交换。 三层交换技术就是：二层交换技术+三层转发技术。它解决了局域网中 网段 划分之后，网段中子网必须依赖路由器进行管理的局面，解决了传统路由器低速、复杂所造成的网络瓶颈问题。 中文名 三层交换技术 别 称 多层交换技术 简 介 二层交换技术+三层转发技术 相 对 传统交换概念 目录 1 概念 ▪ 产生 ▪ 交换原理 ▪ 种类 ▪ 选型 2 应用实例 ▪ 横向比较 ▪ 发展前景 3 概述 ▪ 起源 ▪ 交换技术 ▪ 比较 ▪ 变革 ▪ 演变 4 不足 5 前景分析 6 技术链接 7 控制列表 8 服务质量 9 功能 概念 编辑 三层交换（也称多层交换技术，或IP交换技术）是相对于传统交换概念而提出的。众所周知，传统的交换技术是在OSI 网络标准 模型中的第二层—— 数据链路层 进行操作的，而三层交换技术是在 网络模型 中的第三层实现了 数据包 的高速转发。简单地说，三层交换技术就是：二层交换技术+三层转发技术。 三层交换技术的出现，解决了 局域网 中 网段 划分之后，网段中子网必须依赖 路由器 进行管理的局面，解决了传统路由器低速、复杂所造成的 网络瓶颈 问题。 产生