认知 行动 坚持

看源码，看到这样一段代码：在实现超时connect时候，经常可以这么多，需要set nonblock socket

大家好，我是涛哥。今天还在假期中，最近被朋友拉进了一个乒乓球群，发现了一个打球的地方，又近又好，球友也多，打得挺好，今年减肥有望啦。有很多读者对网络编程很感兴趣，觉得挺有意思，希望我多写一些网络编程方面的实战例子。没问题，这就来了。我写的这些网络程序例子，都是自己亲自调试过的，大家可以直接拿去运行。在后端开发中，并发服务是一个基本的要求，大家手机上的APP连接到后端服务器，这些服务器是怎样处理成千上万的请求的呢？方法有很多，今天，我们来实战fork一下多进程并发服务器。服务端

在实际开发中，我们经常会遇到一些疑难问题。以网络的客户端和服务端为例，经常出现客户端和服务端的现象矛盾，导致僵持不下，怎么确认和处理这类问题呢？ 之前碰到过很多类似问题，最后直接用tcpdump抓包解决。

最近，跟国外一个公司进行联调，需要调用他们的https接口，我在调试时发现，每次调用他们，都会概率性出现403错误，从直观上看，肯定就要找他们帮看具体原因了。 我问了一下对方，但他们非常不responsive，其实，只要他们看一下log或者返回403的逻辑，就很容易知道问题。没办法，只能我自己猜测并尝试。 考虑到他们的接口有IP白名单机制，所以我怀疑是...

说明一下环境：家有无线路由器, 也就是有wifi信息啦，电脑wifi上网，ip为192.168.1.102 , 手机wifi上网, ip为192.168.1.100.        实验：1. 利用电脑ping手机，结果ping不通。                  2. 下载一个手机（我的是小米）终端仿真器，ping电脑，能ping通。                  3. 利用

先说0.0.0.0吧， 他是本机上所有IP的集合。 而127.0.0.1是本机的环回地址，我要说，这就是个鸡肋。      假设PC1(client)的IP为192.168.1.105, PC2(server)的IP为192.168.1.106, 现在考虑网络编程。      pc1去连接 127.0.0.1:8888,     pc2监听0.0.0.0:8888,   连个鸟啊，

看看维基百科的解释：

在家里， 手机和电脑

由于没有找到最原始的位置， 所以我只能给出一个间接地址：http://blog.youkuaiyun.com/zqt520/article/details/17567053       摘录如下：     对于如何在 Linux 底下取得网络接口的状态，过去曾经于”取得网络装置(NETDEVICE)的系统讯息”提过，基本上整个操作是很简单明了的，应该不会有太大的问题。

了解网络的人， 基本上都用过ping命令， 这个优秀的小工具通常能非常靠谱地检测网络的连通性。 但是， 某次， 在某个特殊环境中， 我发现ping不通www.baidu.com但可以访问www.baicom.com网页. 刚开始一看， 这不是矛盾了么？ 后来仔细想想， 觉得没什么不合理的。       ping www.baidu.com会利用到dns协议和icmp协议， 在上述特殊环

我进行了如下图的操作：        我们可以看到， 第一次在pc的cmd中操作arp -a的时候， arp缓存表中并没有手机的相关信息。  此时， 我们让pc来ping一下手机ip, 通过抓包可以看出pc在局域网内广播了arp包， 意思在说： 谁的ip是192.168.1.100, 请告诉我你的mac,  手机受到这个包后， 发现pc喊的正是自己的ip, 于是把自己的mac地址返回，

没有Internet, 两台电脑要通信， 怎么办？我把两台电脑用一根网线连接起来， 分别设置好彼此的IP和掩码（网关可以不用管）， 然后就可以彼此ping通了。 然后， 我在两台电脑上写了客户端和服务端程序（简历了tcp通信通道）， 实现了通信。 进而可以实现文件的传输了。

google protocol buffer（简称pb）是大家常见常用的序列化工具， 有的公司还有自己的私有序列化工具（xxx工具）. 我们平常用的就是xxx工具。 在很多情况下， 序列化出buffer后， 通常会加一个header， 这个header里面有这段buffer的相关信息， 还可能有命令字之类的附带信息。

网卡，又叫网络接口卡(network interface card)，所谓接口，其实就是连接的口子。网卡又叫网络适配器(network adaptor)，所谓适配，其实就是进行适合地配置、转换。下面是网卡的基础知识：      1. 计算机网络，计算机网络，计算机网络。网卡就是计算机与网络的连接设备，其实就是连接cpu与Internet，完成数据格式转换等一系列操作      2. 每个网

无论是在Windows中还是在Linux中，均可以在命令行输入netstat来查看网络连接情况，具体用法又有一些差异，但是我们应该学会查阅。     在Windows中，查阅方式为：netstat /?     在Linux中，查阅方式为：man netstat       其余的，我就不说了，既然知道如何查阅，那就大量实践吧。

不想学网络编程的屌丝说： 我只有一台电脑，不能模拟服务端和客户端，没法进行网络编程； 或者说：我没有网络，没法进行网络编程。 其实，你只需要一台电脑即可， 没有联网也没有关系。靠！你没电脑？ 在cmd中输入netstat -nao | findstr 8888， 然后回车，你一般会得到nothing. 运行下面程序：#include #includ

先看一个服务器程序：#include #include // winsock接口#pragma comment(lib, "ws2_32.lib") // winsock实现int main(){ WORD wVersionRequested; // 双字节，winsock库的版本 WSADATA wsaData; // winsock库版本的相关信息

我们知道， tcp的建立和拆除需要经历三次握手和四次挥手， 那么当客户端与服务器建立了tcp连接之后，突然断掉网线或者掉电， 两侧的tcp状态会有什么变化呢？ 对于不了解tcp的人， 肯能会直接说： 能检测。 我曾经给出了一个貌似正确的答案： 不能检测。

前面讲了抓日志，现在来聊聊抓包。这里讲的抓包，并不是说用手去挠你头上的包包。       我们来看一个初三的物理实验题目：           现在灯泡不亮， 请定位分析。           这个很好办啊，无非就是搞个电压表和电流表呗。           在与网络相关的问题中，也会经常遇到类似的网络问题，遇到问题后， 该怎么办呢？猜测？估计？推脱？ 我晕

我们知道， IP包头有一个16bit的长度， 对应的二进制最大值是2^16 -1，也就是说一个IP包整个长度的最大值是2^16 - 1 字节， 如果考虑UDP通信， 那么除去IP头的20个字节， 除去UDP头的8个字节， 还剩2^16 - 1 - 20 - 8 字节。 我们来玩玩程序（本文只以客户端发数据为例）。

在本文中， 我们谈谈如何搭建一个简易的服务器

先看connect函数：#include #include #include #include #include #include #include #include #include #include #include #include #include #include #include int main(){ int sockClient = s

先说说tcp三次握手，  不细说了， 也就是syn,  ack/syn,  ack.        为什么不能是两次呢？        先假设是两次吧。我们知道， tcp的连接过程中有一个超时重传算法(karn算法是比较典型的)， 如果client发出syn包后， 由于网络原因， 没有立即收到ack/syn包， 那么client会再次发起syn包， 这一点， 我们已经多次实验过。

熟悉IP/TCP包结构的同学一定知道， 在TCP包中， 是没有字段标注整个TCP包长度的， 为什么呢？ 因为完全可以根据IP包的信息来计算出TCP包的长度。 但是， 在IP/UDP中， UDP包头居然给出了整个UDP包的长度， 这个信息不是冗余的吗？       看过《TCP/IP详解》这套书的同学肯定知道， UDP包长信息， 确实是冗余的。 来看看：#include #include

connect函数和accept函数哪个先返回？ 客户端和服务端哪个先完成建立tcp连接？ 这是个有趣的问题， 需要对socket编程和TCP三次握手有所了解。       从三次握手的过程来看， 当然是connect函数先返回啦。       connect正常返回后， 客户端认为建立了TCP连接， accept函数正常返回后， 服务端认为建立了TCP连接。

添加路由是基本技能， 假设自己网关是172.18.18.1, 要访问别的同事的173.18.18.222的pc, 但是又ping不同， 这时候同事说， 你加个路由吧。  好， 那就在cmd中加吧， 加了之后就能ping通过了， 基本技能， 聊作记录：route add 173.18.18.0 mask 255.255.255.0 172.18.18.1

测试同事提单反馈： 工具A的x功能会低概率失效， 但没有发现什么规律。事实上， 我也确实遇到过这个低概率问题， 但是没有深入去分析过它（实际上也不是什么概率不概率， 只要发生了， 就会一直发生， 直到某种条件出现改变）。 前段时间用360抢票， 要回家啊， 抢着抢着， 突然发现， A工具的x功能没法用了， 这次总算是重现到了这个低概率问题。 当时， 我的第一直觉是， 这可能是受了360的影响， 哈哈， 360经常被黑嘛。

先来抽象介绍一下这个bug单.       现象： 测试同事发现， 在局域网内， pc(w.x.y.10)和某设备S(w.x.y.z.20)都 ping不通某ip(w.x.z.30)， 但设备S(w.x.y.z.20)在检测ip(w.x.y.30)的时候， 居然是通过的。       我来翻译一下： pc(w.x.y.10)和某设备S(w.x.y.z.20)都 ping不通某ip(w.x.

与其说复习， 还不如说学习。 大学学的那点计算机网络知识， 早就还给老师了。 不过还得感谢该老师， 没有让我挂科，在此感谢一下。当然，把计算机网络教成一门靠背诵过关的课， 我也是醉了。 先来简要谈一下几个基本的概念。 域名： 不说复杂的， 说简单点， 你可以把它理解为一个串。 DNS服务器： 说白了， 就是一台电脑。 IP: IP就是

前些天， 遇到这样一个古怪的问题： 我的pc与某设备S1进行通信， 结果出现网络频繁断掉的异常情况， 我能基本保证， 我所在的局域网是没有问题的。 而且， 我发现S1设备在另外一个局域网内与别的pc通信， 不会出现网络异常。        这个现象要是让测试MM知道， 说不定要提个概率性问题单呢。 遇到这类古怪的问题， 我慢慢有些经验了， 最重要第一步不是去分析具体代码原因， 而是第一步就要判

谈到网络socket编程， 我们不得不提两个基本也很重要的函数：send和recv. 对socket编程理解不深的童鞋容易产生这样一个错误的认识： send函数是用来发送数据， 而recv函数是用来接收数据的， 其实， 这种观点是稍微有点偏颇的， 掩盖了本质。 下面， 我们看一幅图， 了解一下send和recv函数所处的位置(这幅图是我在网上找的， 不太清晰， 请凑合看一下)：

本文不阐述什么大问题， 仅仅做一个简单的验证：服务端的通信socket号与客户端的通信socket号不一致 下面， 我们看服务端程序：#include #include // winsock接口#pragma comment(lib, "ws2_32.lib") // winsock实现int main(){ WORD wVersionRequested; /

任何计算机网络的教材把什么A, B, C, D, E这几类地址已经讲烂了， 我就不想再嚼了。 本文只为搞清一个问题：公网ip地址w.x.y.z可以用在局域网内吗？       那一年， 我第一次在局域网内用类似于117.1.1.2这样的地址， 于是纳闷了一会儿， 这好像是个公网地址啊！ 好， 在百度输入一下117.1.1.2, 发现是越南的， 但这个ip确实用在局域网中可以正常使用， 而且跟越

在本文中， 我们首先来复习一下telnet命令， 然后聊聊我碰到过的“三次握手”失败经历。 在windows上利用wireshark启动抓包， 然后在cmd中执行telnet www.baidu.com 80， 去访问百度的80端口, 抓包结果如下： 我们看到， 前面两个包是dns请求和回应， 其中101.226.4.6是360推荐给我的dns服务器，

先说明一下， http大牛请绕道行走， 请直接看高手推荐的《HTTP权威指南》 之前， 工作中涉及到一些html, css, js语言， 当初就简单地学了一下， 能顺利处理工作中遇到的问题。 后来又需要进军新的领域， 需要熟悉基于http的soap协议， 于是决定粗略地学习一下http, 期望对http有个基本清晰的了解。

由于没有找到源代码的原作者， 所以就给出一个间接的转载地址：http://blog.youkuaiyun.com/wanxiao009/article/details/5622296， 再次感谢源代码原作者       该程序运行在linux环境下，可以检测ip冲突， 我试过， 挺靠谱的，现摘录如下：#include #include #include #include #inclu

我在局域网内玩某台设备E1，采取的是静态接入方式， ip为172.18.18.20, 可是， 设备E1的网络一会儿正常， 一会儿不正常， 我就手动重启好几次， 发现依然有问题。 百思不得其解， 于是怀疑172.18.18.20这个IP在捣蛋， 后来就干脆停掉了E1， 此时用pc去ping 172.18.18.20， 居然发现这个IP有时候能ping通， 有时候不能ping通。

说明：本文只针对某个特定问题进行分析，定位出的最终结果不具有通用性， 但定位过程是可以揣摩揣摩的。 遇到这样一个问题：没有任何关闭socket的日志，客户端和服务端进程都在， 网络连接完好， 为什么进行某操作后好好的tcp连接莫名其妙地断了呢？ 而且这个问题必现。 首先， 看日志， 没有close socket的任何日志， 而且， 可以确定的是， 如果代码有close socket的操作， 必定有日志输出。 其次， 查看客户端和服务端进程， 发现进程都在，

转载地址： http://www.cnblogs.com/Genesis-007/p/5190552.html                说明： 文中红色部分是我的备注函数原型：1ssize_t recv(int sockfd, void *buf, size_t len, int flags);

今天中秋节， 也算忙了一大天了。 窗外月圆， 我是不是也该吟诵“露从今夜白， 月是故乡明”这样的佳句呢？ 还好， 过几天国庆就要回家了。 今天继续来聊聊http服务器吧！ 在前面的文章中， 我聊过http服务器hfs的搭建和使用， 在本文中， 我们继续来介绍一款很好用的http服务器---lighttpd, 搭建很简单， 也很好用。想学http协议的同学， 可以抓包玩了。