服务器端

Ajax 的实现步骤 1. 创建 ajax 对象 　　　　var xhr = new XMLHttpRequest(); 2. 告诉 ajax 请求地址以及请求方式 (ajax 下的 open 方法 ) 　　　　xhr.open(‘get’,’http://www.example.com’); 第一个参数为请求方式，第二个参数为请求地址/服务器端对应的路由请求地址 3. 发送请求 　　　　xhr.send(); 4. 获取服务器端与客户端的响应数据 　　　　xhr.onload = function () { 　　console.log(xhr.responseText); xhr.responseText 获取服务器端的响应数据 } get请求： 后台对应代码： post请求： xhr.setRequstHeader(‘Content-Type’,’application/x-www-form-urlencoded’); 固定写法 ，第一个参数报文属性名称，第二个参数报文属性对应的值 后台对应代码：（接受post请求要使用一个第三方模块 body-parser） 另外一种客户端向服务器端传递请求方式的格式 - json 格式（post请求） 客户端通过ajax向服务端发送请求参数的格式，除了是属性名称+属性值的格式外，还可以是json格式。 传统的表单默认的是x-www-form

创建服务器端代码托管仓库远程连接仓库 给服务器创建git用户 添加要登录用户的公钥 选定目录作为服务器端代码托管文件夹裸仓库 添加钩子文件 1创建post-receive 2使用vim打开post-receive将如下shell写入文件中 3修改post-receive文件权限 服务器端创建部署项目的文件夹 Git客户端设置 将远程仓库进行克隆 创建测试文件上传到远程仓库 创建服务器端代码托管仓库（远程连接仓库） 给服务器创建git用户 adduser git # 给git用户添加密码 passwd git 添加要登录用户的公钥 mkdir /home/git mkdir .ssh touch authorized_keys #使用vim将公钥添加到authorized_keys文件中,一行一个 Ubuntu公钥生成： http://blog.csdn.net/mrgong_/article/details/78693283 Windows公钥：C:\Users\用户名.ssh 选定目录作为服务器端代码托管文件夹（裸仓库） mkdir /opt/code cd /opt/code git init --bare gongsc.git 添加钩子文件 1、创建post-receive cd /opt/code/gongsc.git touch post-receive 2

以下只是进行了一次的收发例子。 客户端和服务器端是两个解决方案。 服务器端 static void main(string[] args）{ //1.创建Socket对象 Socket tcpServer=new Socket(AddressFamily.InterNetworl,SocketType.Stream,ProtocolType.Tcp); //2.绑定IP和端口号（软件的端口号唯一） IPAddress ipaddress=new IPAddress(new byte[]{192,168,0,112}); EndPoint point=new IPEndPoint(ipaddress,7788); tcpServer.Bind(point);//向操作系统申请一个可用的ip和端口号用来做通信 //3.开始监听（等待客户端连接） tcpServer.Listen(100);//最大连接数 Socket clientSocket=tcpServer.Accept();//暂停当前线程，直到有一个客户端连接过来，之后进行下面的代码 //使用返回的Socke跟客户端做通信 string message="hello 欢迎你"; byte[] data=Encodeing.UTF8.GetBytes(message);//对字符串做编码，得到一个字符串的字节数组

　　在编写udp的时候，用127.0.0.1进行回传。 　　客服端1秒发送4个数据给服务器端 　　服务器10秒接收一次 问题： 　　客服端数据改变，服务器端并不能及时改变 改进： 　　将服务器端也修改成1秒接收一次，刚好同步。 修改： 　　将服务器端修改成3秒一次。 　　前两次不会改变，等到第三次左右才改变。 结论： 　　出现数据叠加在缓冲区中。 需要解决的： 　　缓冲区在哪里？ 来源： https://www.cnblogs.com/zhuangquan/p/11928251.html

TCP协议 Posted on 2019-05-17 18:49 章鱼夫 阅读( 17) 评论( 0) 编辑 收藏 TCP协议全称: 传输控制协议（Transmission Control Protocol ）, 顾名思义, 就是要对数据的传输进行一定的控制. TCP头部: 　　 16位源端口号/16位目的端口号:：表示数据从哪个进程来, 到哪个进程去. 16位数据序号：表示在这个报文段中的第一个数据字节序号 16位确认序号：仅当ACK标志为1时有效。确认号表示期望收到的下一个字节的序号 4位首部长度:：表示该tcp报头有多少个4字节(32个bit) 6位保留:：顾名思义, 先保留着, 以防万 6位标志位： URG: 标识紧急指针是否有效 ACK: 标识确认序号是否有效 PSH: 用来提示接收端应用程序立刻将数据从tcp缓冲区读走 RST: 要求重新建立连接. 我们把含有RST标识的报文称为复位报文段 SYN: 请求建立连接. 我们把含有SYN标识的报文称为同步报文段 FIN: 通知对端, 本端即将关闭. 我们把含有FIN标识的报文称为结束报文段 16位窗口大小：代表的是窗口的字节容量，也就是TCP的标准窗口最大为2^16 - 1 = 65535个字节 16位检验和:：由发送端填充, 检验形式有CRC校验等. 如果接收端校验不通过, 则认为数据有问题.

TCP协议全称: 传输控制协议（Transmission Control Protocol ）, 顾名思义, 就是要对数据的传输进行一定的控制. TCP头部: 　　 16位源端口号/16位目的端口号:：表示数据从哪个进程来, 到哪个进程去. 16位数据序号：表示在这个报文段中的第一个数据字节序号 16位确认序号：仅当ACK标志为1时有效。确认号表示期望收到的下一个字节的序号 4位首部长度:：表示该tcp报头有多少个4字节(32个bit) 6位保留:：顾名思义, 先保留着, 以防万 6位标志位： URG: 标识紧急指针是否有效 ACK: 标识确认序号是否有效 PSH: 用来提示接收端应用程序立刻将数据从tcp缓冲区读走 RST: 要求重新建立连接. 我们把含有RST标识的报文称为复位报文段 SYN: 请求建立连接. 我们把含有SYN标识的报文称为同步报文段 FIN: 通知对端, 本端即将关闭. 我们把含有FIN标识的报文称为结束报文段 16位窗口大小：代表的是窗口的字节容量，也就是TCP的标准窗口最大为2^16 - 1 = 65535个字节 16位检验和:：由发送端填充, 检验形式有CRC校验等. 如果接收端校验不通过, 则认为数据有问题. 此处的校验和不光包含TCP首部, 也包含TCP数据部分. 16位紧急指针:：用来标识哪部分数据是紧急数据. TCP的三次握手： 　　

TCP协议全称: 传输控制协议（Transmission Control Protocol ）, 顾名思义, 就是要对数据的传输进行一定的控制. TCP头部: 　　 16位源端口号/16位目的端口号:：表示数据从哪个进程来, 到哪个进程去. 16位数据序号：表示在这个报文段中的第一个数据字节序号 16位确认序号：仅当ACK标志为1时有效。确认号表示期望收到的下一个字节的序号 4位首部长度:：表示该tcp报头有多少个4字节(32个bit) 6位保留:：顾名思义, 先保留着, 以防万 6位标志位： URG: 标识紧急指针是否有效 ACK: 标识确认序号是否有效 PSH: 用来提示接收端应用程序立刻将数据从tcp缓冲区读走 RST: 要求重新建立连接. 我们把含有RST标识的报文称为复位报文段 SYN: 请求建立连接. 我们把含有SYN标识的报文称为同步报文段 FIN: 通知对端, 本端即将关闭. 我们把含有FIN标识的报文称为结束报文段 16位窗口大小：代表的是窗口的字节容量，也就是TCP的标准窗口最大为2^16 - 1 = 65535个字节 16位检验和:：由发送端填充, 检验形式有CRC校验等. 如果接收端校验不通过, 则认为数据有问题. 此处的校验和不光包含TCP首部, 也包含TCP数据部分. 16位紧急指针:：用来标识哪部分数据是紧急数据. TCP的三次握手： 　　

TCP协议全称: 传输控制协议（Transmission Control Protocol ）, 顾名思义, 就是要对数据的传输进行一定的控制. TCP头部: 　　 16位源端口号/16位目的端口号:：表示数据从哪个进程来, 到哪个进程去. 16位数据序号：表示在这个报文段中的第一个数据字节序号 16位确认序号：仅当ACK标志为1时有效。确认号表示期望收到的下一个字节的序号 4位首部长度:：表示该tcp报头有多少个4字节(32个bit) 6位保留:：顾名思义, 先保留着, 以防万 6位标志位： URG: 标识紧急指针是否有效 ACK: 标识确认序号是否有效 PSH: 用来提示接收端应用程序立刻将数据从tcp缓冲区读走 RST: 要求重新建立连接. 我们把含有RST标识的报文称为复位报文段 SYN: 请求建立连接. 我们把含有SYN标识的报文称为同步报文段 FIN: 通知对端, 本端即将关闭. 我们把含有FIN标识的报文称为结束报文段 16位窗口大小：代表的是窗口的字节容量，也就是TCP的标准窗口最大为2^16 - 1 = 65535个字节 16位检验和:：由发送端填充, 检验形式有CRC校验等. 如果接收端校验不通过, 则认为数据有问题. 此处的校验和不光包含TCP首部, 也包含TCP数据部分. 16位紧急指针:：用来标识哪部分数据是紧急数据. TCP的三次握手： 　　

版权声明： 本博客欢迎转载，转载时请以超链接形式标明文章原始出处！谢谢！ 博客地址： http://blog.csdn.net/i_chips 1. 基本术语 AJAX（Asynchronous JavaScript And XML，异步JavaScript和XML）：AJAX是一种用于创建快速动态网页的技术，通过在后台与服务器进行少量数据交换，AJAX可以使网页实现异步更新。这意味着可以在不重新加载整个网页的情况下，对网页的某部分进行更新。 JSON（JavaScript Object Notation）：JSON是一种轻量级的数据交换格式，可以看成是由大括号包裹起来的多个"key/value"对，格式如下：{"firstName":"Brett", "lastName":"McLaughlin", "email":"abcdefg@gmail.com"}。 Cross Domain（跨域）：跨域问题是由于JavaScript语言安全限制中的同源策略造成的，当在页面上使用AJAX请求访问其他服务器的数据时，客户端就会出现跨域问题。 Same Origin Policy（同源策略）：同源策略是指一段脚本只能读取来自同一来源的窗口和文档的属性，域名、协议、端口均相同，即是同源。 2. JavaScript跨域解决方案 目前主要有三种JavaScript跨域解决方案：

前言 随着移动应用的发展和推广，APP应用安全越来越受到重视。APP中各类防抓包的机制的出现，让测试无法正常进行分析。 这篇文章算是总结一下我最近遇到的一款抓不到包的APP，给大家提供一个双向证书认证应该如何解决的思路。 判断证书双向认证 刚拿到此app时候常规方法一把梭，发现只要一开启手机代理，却提示网络异常，通过观察burpsuite的记录发现，只有请求包而没有响应包。 直觉告诉我应该是使用SSL Pinning防止中间人拦截攻击，然后我开启了ssl-kill-switch2后发现该APP所有的响应包返回 400 No required SSL certificate was sent的报错信息。 根据报错提示，搜了一下发现该错误是指服务器端启用了证书双向认证。 当服务器启用了证书双向认证之后，除了客户端去验证服务器端的证书外，服务器也同时需要验证客户端的证书，也就是会要求客户端提供自己的证书，如果没有通过验证，则会拒绝连接，如果通过验证，服务器获得用户的公钥。 该app直接封装了客户端的证书，相比于单项认证，无非就是多了一个服务器端验证客户端证书的过程，而在以往的用代理工具如burp这类工具，抓取https的包时，除了浏览器获取的是代理工具的证书外，默认是不发送证书给服务器端的。burp在抓取https报文的过程中也提供了双向认证的证书发送，但是是使用了burp提供的证书文件