tcp

Difference between skb_header_pointer and skb_transport_header?

梦想与她 提交于 2020-03-26 04:29:06
问题 I'm trying to implement a netfilter module, while processing sk_buff I found two possible ways to retrieve TCP header: struct iphdr *ip_header = (struct iphdr *)skb_network_header(skb); struct tcphdr *tcp_header = (struct tcphdr *)skb_transport_header(skb); And struct iphdr *ip_header = skb_header_pointer(skb, 0, sizeof(struct iphdr), &_iph) struct tcphdr *tcp_header = skb_header_pointer(skb, ip_header->ihl * 4, sizeof(struct tcphdr), &_tcph); Which one should I use? 回答1: You should use ip

20199303 2019-2020-2 《网络攻防实践》第4周作业

混江龙づ霸主 提交于 2020-03-25 21:28:42
学习总结 Sniffer(嗅探器) 嗅探器是一种常用的收集有用数据方法,这些数据可以是用户的帐号和密码,可以是一些商用机密数据等等。Snifffer可以作为能够捕获网络报文的设备,ISS为Sniffer这样定义:Sniffer是利用计算机的网络接口截获目的地为其他计算机的数据报文的一种工具。 SNIFFER要捕获的东西必须是要物理信号能收到的报文信息。显然只要通知网卡接收其收到的所有包(一般叫做杂收promiscuous模式:指网络上的所有设备都对总线上传送的数据进行侦听,并不仅仅是它们自己的数据。),在HUB下就能接收到这个网段的所有包,但是交换机下就只能是自己的包加上广播包。 要想在交换机下接收别人的包,那就要让其发往你的机器所在口。交换机记住一个口的MAC是通过接收来自这个口的数据后并记住其源MAC,就像一个机器的IP与MAC对应的ARP列表,交换机维护一个物理口与MAC的表,所以可以欺骗交换机的。可以发一个包设置源MAC是你想接收的机器的MAC,那么交换机就把你机器的网线插的物理口与那个MAC对应起来了,以后发给那个MAC的包就发往你的网线插口了,也就是你的网卡可以Sniffer到了。注意这物理口与MAC的表与机器的ARP表一样是动态刷新的,那机器发包后交换HUB就又记住他的口了,所以实际上是两个在争,这只能应用在只要收听少量包就可以的场合。

网络协议,如TCP/UDP的区别?

不打扰是莪最后的温柔 提交于 2020-03-25 13:33:20
1、TCP面向连接(如打电话要先拨号建立连接);UDP是无连接的,即发送数据之前不需要建立连接 2、TCP提供可靠的服务。也就是说,通过TCP连接传送的数据,无差错,不丢失,不重复,且按序到达;UDP尽最大努力交付,即不保证可靠交付 3、TCP面向字节流,实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的 UDP没有拥塞控制,因此网络出现拥塞不会使源主机的发送速率降低(对实时应用很有用,如IP电话,实时视频会议等) 4、每一条TCP连接只能是点到点的;UDP支持一对一,一对多,多对一和多对多的交互通信 5、TCP首部开销20字节;UDP的首部开销小,只有8个字节 6、TCP的逻辑通信信道是全双工的可靠信道,UDP则是不可靠信道 三次握手与四次挥手 三次握手通俗版: 第一次握手:客户端要和服务端进行通信,首先要告知服务端一声,遂发出一个SYN=1的连接请求信号,”服务端哥哥,我想给你说说话”。 第二次握手:当服务端接收到客户端的连接请求,此时要给客户端一个确认信息,”我知道了(ACK),我这边已经准备好了,你现在能连吗(SYN)”。 第三次握手:当客户端收到了服务端的确认连接信息后,要礼貌的告知一下服务端,“好的,咱们开始联通吧(ACK)”。 到此整个建立连接的过程已经结束,接下来就是双方你一句我一句甚至同时交流传递信息的过程了。 四次挥手断开连接通俗版: 第一次挥手

详解TCP建立连接全过程

倖福魔咒の 提交于 2020-03-25 07:39:42
TCP是因特网中的传输层协议,使用三次握手协议建立连接,下面是TCP建立连接的全过程。 上图画出了TCP建立连接的过程。假定主机A是TCP客户端,B是服务端。最初两端的TCP进程都处于CLOSED状态。图中在主机下面的是TCP进程所处的状态。A是主动打开连接,B是被动打开连接。 首先A向B发出连接请求报文段,这时首部中的同步位SYN=1,同时选择一个初始序号seq=x。TCP规定,SYN报文段不能携带数据,但要消耗掉一个序号。这时,A进入SYN-SENT状态。 B收到请求后,向A发送确认。在确认报文段中把SYN和ACK位都置为1,确认号是ack=x+1,同时也为自己选择一个初始序号seq=y。请注意,这个报文段也不能携带数据,但同样要消耗掉一个序号。这时B进入SYN-RCVD状态。 A收到B的确认后,还要向B给出确认。确认报文段的ACK置为1,确认号ack=y+1,而自己的序号seq=x+1。这时,TCP连接已经建立,A进入ESTABLISHED状态,当B收到A的确认后,也会进入ESTABLISHED状态。 以上给出的连接建立过程就是常说的TCP三次握手。 为什么A还要发送一次确认呢?这主要是为了防止已失效的连接请求报文段突然又传送到了B,因而产生错误。 所谓已失效的连接请求报文段是这样产生的。A发送连接请求,但因连接请求报文丢失而未收到确认,于是A重发一次连接请求

计算机网络课设之TCP通讯录

本小妞迷上赌 提交于 2020-03-25 07:33:13
这篇文章我主要是想对这学期末计算机网络课程设计所做的一个小项目也就是基于tcp协议的通讯录做一个总结梳理。项目的具体的代码实现是基于C语言,当然在此之前网上也有一些基于c++编写的tcp通讯录,原理都是相同的,最基本的还是如何灵活运用Socket套接字来发送和接受数据。因为之前并未系统学过有关socket通信的知识,所以在正式开始动手之前,博主还是查阅了一些相关的书籍,有了基本的知识储备,才能为后续的项目开发提供保障。废话不多说,开始进入正文。 开发环境:windows 10 开发工具: Visual Studio2017 1.首先要了解在 tcp/ip网络环境下的客户端主机和服务器端主机的通信流程。即C/S模型。客户端在需要提供服务时向服务端发出请求,服务端等待客户端提出请求,服务端始终运行,监听网络接口,收到client请求启动服务进程响应客户同时继续监听服务窗口,保证后续的client也能连接上服务。 2. 其次要掌握 tcp通信所需要的几个主要功能函数。这里可以参考 http://www.cnblogs.com/yuqiao/p/5786427.html 3.掌握面向连接的C/S程序的工作流程 服务端 : 在服务端首先使用 WSAStartup()函数检查系统协议栈使用情况 使用 socket()函数创建服务器端的通信套接口 使用 bind(

关于一次配合开发工作而产生的服务器内核参数问题(Android 网络问题)

北慕城南 提交于 2020-03-25 06:50:50
关于一次配合开发工作而产生的服务器内核参数问题(Android 网络问题) 问题转载(本人与作者遇到了同样的问题) 问题描述 问题描述: 在这几年的Android开发中,遇到了一个困扰我好久的问题,有时候在公司的wifi下,请求我们的公司自己的服务器很慢,甚至经常请求失败,切换成移动网络3G或者4G,就明显变快。but在相同的wifi环境下,用iphone和电脑请求就很快 刚开始发现手机wifi很慢的时候,以为是公司网络的问题,所以找运维去解决,运维的解释是我们公司用的北京鹏博士的宽带,公司机房是用的北京联通的宽带,公司的网络连接公司的服务器要经过武汉的转接点才能连到公司的服务器,绕了一个大圈,导致请求变慢,解决方法是 接入多个运营商 ,但是由于公司预算的问题,这个没法解决。 后来发现只有Android手机连接服务器比较慢,iPhone和windows电脑请求都正常,我猜想可能是应用的网络请求框架有问题,因此专门写了一个demo,用Android提供的HttpUrlConnection直接请求,然后又用系统浏览器直接请求接口,也有同样的问题,排除了框架问题的可能。 难道是Android手机的wifi模块质量比较次,所以我把手头所有Android手机都测试了一遍,不管是贵的,还是便宜的,可能爆炸的还是工匠精神的都有此问题,并且还发现在家里的wifi下速度嗖嗖的

网络编程之socket新解

这一生的挚爱 提交于 2020-03-25 03:49:31
   由于工作并不是很忙,闲暇之余就读了下tomcat的源代码。我是从事java服务器开发工作的,大体的一些服务器线程模型我都是了解的。其大部分都是由一个线程调用监听端口等待客户端的链接,建立连接后再交由其他的线程负责具体的网络io操作。可tomcat居然是用多个线程调用同一个ServerSocket实例的accept方法。我读过mina也读过netty的源码,自己在大学时也写过不少的基于socket通信的程序,但是这种用法自己从未想过也从未见过。(恕本人咕噜寡闻了,-_-|||)不免好奇,这么做原来没问题啊?可这么做能有什么好处吗?   要明白这么做的道理,恐怖不得不去搞清楚套接字的accept方法底层到底干了什么,与TCP的三步握手又是什么关系。我查了一些资料大体把这些搞明白了,在这里记录下来以加强自己的认识,也同时共享给哪些跟我一样对socket的认识有所偏差的人。   一、首先说一下TCP三步握手的基本流程,如下图:   首先,请求端(客户端)发送一个包含SYN标志的TCP报文,SYN即同步(Synchronize),同步报文会指明客户端使用的端口以及TCP连接的初始序号;   第二步,服务器在收到客户端的SYN报文后,进入SYN-RECEVIED状态并将这个还没有完全建立起的连接放到半连接队列。还要返回一个SYN+ACK的报文,表示客户端的请求被接受,同时TCP序号被加一

TCP简介

扶醉桌前 提交于 2020-03-25 03:47:59
TCP介绍 TCP协议,传输控制协议(英语:Transmission Control Protocol,缩写为 TCP) 是一种面向连接的、可靠的、基于字节流的传输层通信协议,由IETF的RFC 793定义。 TCP通信需要经过 创建连接、数据传送、终止连接 三个步骤。 TCP通信模型中,在通信开始之前,一定要先建立相关的链接,才能发送数据,类似于生活中,"打电话"" TCP特点 1. 面向连接 通信双方必须先建立连接才能进行数据的传输,双方都必须为该连接分配必要的系统内核资源,以管理连接的状态和连接上的传输。 双方间的数据传输都可以通过这一个连接进行。 完成数据交换后,双方必须断开此连接,以释放系统资源。 这种连接是一对一的, 因此TCP不适用于广播的应用程序,基于广播的应用程序请使用UDP协议。 2. 可靠传输 1) TCP采用发送应答机制 TCP发送的每个报文段都必须得到接收方的应答才认为这个TCP报文段传输成功 2) 超时重传 发送端发出一个报文段之后就启动定时器,如果在定时时间内没有收到应答就重新发送这个报文段。 TCP为了保证不发生丢包,就给每个包一个序号,同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的包发回一个相应的确认(ACK);如果发送端实体在合理的往返时延(RTT)内未收到确认,那么对应的数据包就被假设为已丢失将会被进行重传。 3)

一起学Python:TCP简介

青春壹個敷衍的年華 提交于 2020-03-25 03:47:13
一起学Python:TCP简介 TCP介绍 TCP协议,传输控制协议(英语:Transmission Control Protocol,缩写为 TCP) 是一种面向连接的、可靠的、基于字节流的传输层通信协议,由IETF的RFC 793定义。 TCP通信需要经过 创建连接、数据传送、终止连接 三个步骤。 TCP通信模型中,在通信开始之前,一定要先建立相关的链接,才能发送数据,类似于生活中,"打电话"" TCP特点 1. 面向连接 通信双方必须先建立连接才能进行数据的传输,双方都必须为该连接分配必要的系统内核资源,以管理连接的状态和连接上的传输。 双方间的数据传输都可以通过这一个连接进行。 完成数据交换后,双方必须断开此连接,以释放系统资源。 这种连接是一对一的, 因此TCP不适用于广播的应用程序,基于广播的应用程序请使用UDP协议。 2. 可靠传输 1) TCP采用发送应答机制 TCP发送的每个报文段都必须得到接收方的应答才认为这个TCP报文段传输成功 2) 超时重传 发送端发出一个报文段之后就启动定时器,如果在定时时间内没有收到应答就重新发送这个报文段。 TCP为了保证不发生丢包,就给每个包一个序号,同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的包发回一个相应的确认(ACK);如果发送端实体在合理的往返时延(RTT)内未收到确认

一起学Python:TCP简介

主宰稳场 提交于 2020-03-25 03:46:55
一起学Python:TCP简介 TCP介绍 TCP协议,传输控制协议(英语:Transmission Control Protocol,缩写为 TCP) 是一种面向连接的、可靠的、基于字节流的传输层通信协议,由IETF的RFC 793定义。 TCP通信需要经过 创建连接、数据传送、终止连接 三个步骤。 TCP通信模型中,在通信开始之前,一定要先建立相关的链接,才能发送数据,类似于生活中,"打电话"" TCP特点 1. 面向连接 通信双方必须先建立连接才能进行数据的传输,双方都必须为该连接分配必要的系统内核资源,以管理连接的状态和连接上的传输。 双方间的数据传输都可以通过这一个连接进行。 完成数据交换后,双方必须断开此连接,以释放系统资源。 这种连接是一对一的, 因此TCP不适用于广播的应用程序,基于广播的应用程序请使用UDP协议。 2. 可靠传输 1) TCP采用发送应答机制 TCP发送的每个报文段都必须得到接收方的应答才认为这个TCP报文段传输成功 2) 超时重传 发送端发出一个报文段之后就启动定时器,如果在定时时间内没有收到应答就重新发送这个报文段。 TCP为了保证不发生丢包,就给每个包一个序号,同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的包发回一个相应的确认(ACK);如果发送端实体在合理的往返时延(RTT)内未收到确认