Network: Explain the relationship between UDP and TCP from the perspective of socket programming, the difference between http and tcp

News 2023-08-11 22:55:30 views: null

         Attempts to explain various network protocols from a programming perspective.

The relationship between UDP and TCP

        From the perspective of Python socket programming, UDP ( User Datagram Protocol) and TCP ( Transmission Control Protocol) are two different transmission protocols.

  • TCP is a connection-oriented protocol that provides reliable, ordered, bidirectional data transmission. In TCP, a connection must first be established between the client and the server, then data is transmitted through the connection, and finally the connection is closed. TCP guarantees the reliability of data, and ensures the orderly transmission of data through mechanisms such as congestion control and flow control.
  • UDP is a connectionless protocol that provides unreliable, out-of-order, packet-oriented data transmission. In UDP, there is no need to establish a connection between the client and the server, and data transmission can be performed directly. UDP does not guarantee data reliability, nor does it have mechanisms such as congestion control and flow control. It is suitable for some applications with high real-time requirements, such as streaming media.

        In Python socket programming, you can use the socket module to create UDP and TCP sockets for network communication. When using a UDP socket for communication, you can send and receive UDP packets through the sendto() and recvfrom() methods of the socket. When using TCP sockets for communication, you can establish a connection through the socket's connect() method, and then use the send() and recv() methods for data transmission.

code

Here is a sample code using UDP sockets:

import socket

# 创建UDP套接字
udp_socket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

# 发送UDP数据报文
udp_socket.sendto(b"Hello, UDP", ("127.0.0.1", 8888))

# 接收UDP数据报文
data, addr = udp_socket.recvfrom(1024)
print("Received:", data.decode())

# 关闭UDP套接字
udp_socket.close()

Here is a sample code using TCP sockets:

import socket

# 创建TCP套接字
tcp_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)# 创建TCP欢迎套接字，使用IPv4协议

# 建立TCP连接
tcp_socket.connect(("127.0.0.1", 8888))# 向服务器发起连接，先进行三次握手，然后建立TCP连接

# 发送TCP数据
tcp_socket.send(b"Hello, TCP")

# 接收TCP数据   从服务器接收信息
data = tcp_socket.recv(1024)
print("Received:", data.decode())

# 关闭TCP连接
tcp_socket.close()


import socket 
# 创建TCP套接字
serverSocket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) 

# 将TCP欢迎套接字绑定到端口8899
serverSocket.bind(("127.0.0.1", 8888)) 

# 定义最大连接数
serverSocket.listen(10) 
print("server start")

while True:
    # 接收到客户连接请求后，调用accept()方法，创建新的TCP连接套接字，由这个客户专用；进行握手后建立一个TCP连接
	connectionSocket, addr = serverSocket.accept() 
 
	# 获取客户发送的字符串
	sentence = connectionSocket.recv(1024) 
 
	# 向用户发送修改后的字符串
	connectionSocket.send(b"ni hao") # a bytes-like object
 
    # 关闭TCP连接套接字
	connectionSocket.close()

insert image description here

  • Similar project: Simple Cli chat room implemented with Python Socket TCP https://github.com/FlyAndNotDown/ChatRoom/blob/master/server/server.py
    insert image description here

http

  • The http protocol is above the ip protocol, right?
    irrelevant. I can write the HTTP request text by hand, write it on paper and send it by post. After receiving it, the other party can read the content with a stare, and write the response on paper and send it back for me to read. There is no IP protocol involved in the whole process.

code

The difference between http and tcp

        Hypertext Transfer Protocol is a request and response based, stateless, application layer protocol, so its focus is on text, while tcp focuses on transmission.
        The http protocol is just a protocol agreed between software, defined in the following format:

  • Request line carriage return + line feed, request header carriage return + line feed, request header carriage return + line feed... Request header carriage return + line feed carriage return + line feed data

Long and short connections

In network communication, long connection and short connection refer to the length of time to establish a connection between the client and the server.

  1. Long connection: A long connection means that the connection established between the client and the server can remain open for a long time. Once a persistent connection is established, the client and server can perform multiple data transfers without re-establishing the connection each time.

  2. Short connection: A short connection means that the connection established between the client and the server is short-lived, and once the data transmission is completed, the connection will be closed. The connection needs to be re-established for each communication, and the connection is closed immediately after the transfer is completed. The above example is a short link.

  • The implementation of long connections usually needs to consider the following aspects:

  1. Keep the connection: In order to achieve a long connection, the client and the server need to keep the connection open. This is accomplished by sending periodic heartbeats between the client and server to ensure the connection is kept alive. The heartbeat signal can be an empty data packet or specific control information, which is used to inform the other party that the connection still exists.

  2. Connection management: The server needs to maintain and manage the connection status of the client. This includes registering connections with the server, disconnecting or closing idle connections, etc. Servers need to manage connections with data structures such as hash tables or connection pools to ensure efficient processing and response to client requests.

  3. Optimize network resources: Long connections will occupy server resources, so network resources need to be optimized. This includes reasonably limiting the number of simultaneous connections, enabling the server to handle other requests, and closing or reusing connections that have been idle for a long time.

  4. Exception handling and fault tolerance mechanism: Considering that long connections may be interrupted due to network interruption, server failure or other abnormalities, exception handling and fault tolerance mechanisms need to be implemented. This can include reconnection mechanism, connection timeout judgment and recovery mechanism, etc., to ensure the stability and reliability of the connection.

  5. Heartbeat detection: In order to keep the connection alive, the client and server can perform heartbeat detection periodically. If the heartbeat signal is not received within a certain period of time, it can be judged that the connection has been disconnected, and then the connection can be re-established.

  6. Session management and authentication: In a persistent connection, for each connection, session management and authentication are required. This ensures that only authenticated users can use persistent connections and that each session can be personalized.

DNS - IP address lookup

  • When a user enters a domain name in the browser, the operating system will send a DNS query request to the local DNS resolver. The local DNS resolver will first query whether the IP address corresponding to the domain name exists in the local cache. If not, it will issue a query request to the root name server. The root name server will return a set of IP addresses of the top-level name servers, and then the local DNS resolver will send the query to the top-level name servers. This process will iterate step by step until the IP address corresponding to the target domain name is obtained. Once the local DNS resolver has obtained the IP address corresponding to the domain name, it will return this result to the operating system, and the operating system will pass it on to the user's application program, such as a browser. The application can then use this IP address to communicate with the remote server. DNS uses TCP and UDP port 53. Currently, the limit for the length of domain names at each level is 63 characters, and the total length of domain names cannot exceed 253 characters.

  • DNS adopts a caching mechanism. Once the resolution result of a domain name is cached by the local DNS server, subsequent queries will be faster and network delays will be reduced. In addition, DNS also supports technologies such as recursive query and iterative query, which can further improve query efficiency. If the local DNS server does not cache the resolution result of a certain domain name, it must send a query request to the upper-layer DNS server. This query and response process may cause a certain query delay.

related items

  • DNSChef is a network security tool used to intercept and modify DNS (Domain Name System) queries and responses for the purpose of DNS spoofing. It allows users to control specific network communications by redirecting specific DNS queries to user-defined IP addresses or domain names.

DNSChef works as follows:

  1. DNS query interception: DNSChef can intercept DNS query requests sent by the target computer by running a proxy on the local computer as a DNS server. When a target computer initiates a DNS query, it sends the query to the DNSChef proxy instead of the real DNS server. This way, DNSChef is able to inspect and modify that DNS query.

  2. DNS query modification: Once DNSChef captures the DNS query request, it can modify the query according to the user's settings. Users can set custom IP addresses to redirect queries to specified IP addresses. You can also set a custom domain name to redirect queries to the specified domain name. In addition, other information in the DNS query, such as TTL (time to live), can also be modified as needed.

  3. DNS Response Simulation: In addition to intercepting and modifying DNS queries, DNSChef can also simulate DNS responses. It can generate custom DNS responses based on user's settings and return them to the target computer. This can be used for purposes such as phishing attacks, network monitoring and debugging.

  • https://github1s.com/bigsnarfdude/pythonNetworkProgrammingN00B/blob/master/dnschef.py
  • https://github.com/dweekly/dnschat
  • https://github.com/soobbu/PeerLink

arp - physical address query

        ARP (Address Resolution Protocol) is a protocol for resolving IP addresses to corresponding MAC addresses, and it 局域网works internally. Using ARP, computer A can use an IP address to send a request ( ) to every computer in the area 发送方发送ARP请求广播. If another computer will IP 识别为自己的 IP, then it's ok 使用相应的 MAC 地址进行响应. When computer A receives the response, it knows how to send its original message down the data link layer.

        The following is the working process of ARP:

  1. When a host (sender) wants to send a data packet to another host (target), it first checks its own ARP cache table (ARP Cache) to see if it already has the MAC address corresponding to the IP address of the target host. If there is a corresponding cache entry, the sender can directly use the MAC address.

  2. If there is no MAC address of the target host in the ARP cache, the sender will send an ARP request broadcast packet (ARP Request Broadcast) to all hosts on the LAN. The broadcast packet includes the sender's IP address and MAC address.

  3. The host (including the target and other hosts) that receives the ARP request broadcast will check whether its own IP address 广播包matches the target IP address in the ARP request. If it matches, it sends its own MAC address to the sender to form an ARP response (ARP Reply).

  4. After the sender receives the ARP response, it saves the IP address and MAC address of the target host in the ARP cache table for future use.

  5. Once the sender has the MAC address of the target host, it can construct a packet with the MAC address of the target host and send it to the target host. After the target host receives the data packet, it judges whether to receive the data packet according to its own IP address.

related items

  • arpchat｜Online chat tool implemented with ARP protocol https://github.com/kognise/arpchat

CG

OSI seven-layer model

Open System Interconnection Reference Model (OSI)

  • Physical layer, data link layer, network layer, transport layer, session layer, presentation layer, application layer

Physical layer: use the transmission medium to provide a physical connection for the data link layer, and realize the transparent transmission of the bit stream.
Data Link Layer: Responsible for establishing and managing links between nodes.
Network layer: Through the routing selection algorithm, select the most appropriate path for the message or packet to pass through the communication subnet.
Transport layer: Provide users with reliable end-to-end error and flow control to ensure the correct transmission of messages.
Session layer: Provides methods for establishing and using connections to the presentation layers of two entities.
Presentation layer: Deal with the representation of user information, such as encoding, data format conversion, encryption and decryption, etc.
Application layer: Provide services directly to users and complete various tasks that users want to complete on the network.

Guess you like

Origin blog.csdn.net/ResumeProject/article/details/130612428
Recommended
Ranking
vue project automated build tools 1.0, support for multi-page build
JDBC add, update, delete data
SpringCloud combat service in response to the decline tutorial series (Chapter IV)
A segmentation fault (core dumped) error occurs when C+11 compiles and calls the PCL library
Django achieve websocket
Go语言并发之道--笔记1
Three-tier structure and application
Zhejiang data structure after-school exercise practice two 7-2 Reversing Linked List (25 points)
Front-end interview brushing day9 (updated daily high-frequency inspection points for front-end interviews)
The difference between the shell of the single and double quote
Daily
More
2024-05-02(0)
2024-05-01(4)
2024-04-30(36)
2024-04-29(5)
2024-04-28(12)
2024-04-27(29)
2024-04-26(22)
2024-04-25(32)
2024-04-24(30)
2024-04-23(30)

Code World

© 2018 codetd.com