Какие знаешь протоколы передачи данных?

Протоколы передачи данных: мой опыт

Я работал с различными протоколами передачи данных при тестировании разнообразных приложений. Это критически важное знание для QA инженера, особенно при тестировании networking, API и интеграций.

TCP/IP Stack

IP (Internet Protocol)

Версии: IPv4, IPv6

Характеристики:

• Основной протокол маршрутизации в интернете
• IP-адреса: IPv4 (4 октета: 192.168.1.1), IPv6 (128 бит)
• Connectionless (no handshake)
• Best-effort delivery (не гарантирует доставку)

При тестировании:

• Проверяю, что приложение работает на IPv4 и IPv6
• Тестирую на сетях с ограничениями IP

TCP (Transmission Control Protocol)

Характеристики:

• Connection-oriented (трёхшаговое handshake: SYN, SYN-ACK, ACK)
• Гарантирует доставку и порядок пакетов
• Надёжный, но медленнее UDP

Ports:

• 21: FTP
• 22: SSH
• 80: HTTP
• 443: HTTPS
• 3306: MySQL
• 5432: PostgreSQL

При тестировании:

• Проверяю connection timeout'ы (когда server не отвечает)
• Тестирую graceful shutdown (корректное закрытие connection)
• Мониторю TIME_WAIT состояние сокетов

UDP (User Datagram Protocol)

Характеристики:

• Connectionless (no handshake)
• Не гарантирует доставку
• Быстрее, чем TCP
• Used для: DNS, Video streaming, Online games, VOIP

При тестировании:

• Проверяю обработку потерянных пакетов
• Тестирую performance (UDP быстрее)
• Проверяю retry логику

Пример из практики: Тестировал VOIP приложение. UDP потеря 1-2% пакетов — нормально, система должна справиться. Когда потеря > 10%, качество звука деградирует. Это требовало специальных тестов.

HTTP и HTTPS

HTTP/1.1

Характеристики:

• Text-based protocol
• Stateless (каждый запрос независим)
• Methods: GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS
• Status codes: 2xx (success), 3xx (redirect), 4xx (client error), 5xx (server error)

Headers:

• Content-Type: application/json
• Content-Length
• Authorization: Bearer token
• Cache-Control
• Set-Cookie

При тестировании HTTP:

1. Проверяю correct HTTP method
   - GET для чтения (должен быть idempotent)
   - POST для создания
   - PUT для обновления
   - DELETE для удаления

2. Проверяю status codes
   - 200 OK
   - 201 Created
   - 400 Bad Request
   - 401 Unauthorized
   - 403 Forbidden
   - 404 Not Found
   - 500 Internal Server Error

3. Проверяю headers
   - Correct Content-Type
   - Security headers (X-Frame-Options, CSP, etc)
   - CORS headers
   - Cache headers

4. Проверяю body
   - JSON валиден
   - Структура matches спецификации
   - Encoding правильный (UTF-8)

HTTP/2

Улучшения над HTTP/1.1:

• Multiplexing (несколько запросов одновременно)
• Server push
• Compression (HPACK)
• Binary protocol (вместо text)

При тестировании:

• Проверяю, что server правильно обрабатывает multiplexing
• Тестирую performance улучшения
• Проверяю совместимость с HTTP/1.1

HTTP/3 (QUIC)

Новое в HTTP/3:

• Based on QUIC protocol
• Faster handshake
• Better performance на медленных сетях
• Connection migration (может переключаться между WiFi и LTE)

Current state: HTTP/3 ещё не так распространён, но растёт. Я тестировал приложения, готовящиеся к HTTP/3.

HTTPS (HTTP + TLS/SSL)

Security:

• Шифрование данных в transit
• Certificate validation
• TLS handshake

При тестировании:

• Проверяю SSL certificate валиден
• Тестирую expired certificate (должна быть ошибка)
• Проверяю TLS version (должен быть 1.2+)
• Тестирую cipher suites

Пример: Обнаружил баг — приложение принимало самоподписанные сертификаты в production. Исправили на требование валидного сертификата.

WebSocket

Использование:

• Real-time communication
• Chat приложения
• Live notifications
• Collaborative editing

Характеристики:

• Persistent connection (не закрывается после каждого сообщения)
• Bidirectional (client ↔ server)
• Lower latency

При тестировании:

1. Connection establishment
   - WebSocket handshake successful
   - Connection открывается

2. Message delivery
   - Messages доставляются в порядке
   - No message loss
   - Latency < threshold

3. Reconnection
   - Client reconnects при разрыве
   - Missed messages не теряются

4. Scale
   - 1000 concurrent connections работают
   - Message broadcast работает

Практический пример: Тестировал real-time collaboration app. WebSocket соединение разрывалось каждые 5 минут. Нашли баг в load balancer — не правильно обрабатывал WebSocket. После fix — стабильно 99.9%.

FTP / SFTP

FTP (File Transfer Protocol):

• Передача файлов
• Port: 21
• Username/password authentication
• Plain text (no encryption)
• Deprecated, используют SFTP вместо

SFTP (SSH File Transfer Protocol):

• Secure, encrypted FTP
• Port: 22 (SSH)
• Better authentication
• Preferred для file transfer

При тестировании:

• Проверяю upload файлов
• Проверяю download файлов
• Проверяю file integrity (MD5, SHA256)
• Тестирую large files
• Проверяю permission'ы

DNS (Domain Name System)

Функция: Resolves domain name → IP address

Пример:

User: "посети example.com"
DNS resolver: "Найди IP для example.com"
Result: "93.184.216.34"

При тестировании:

• Проверяю, что DNS resolution работает
• Тестирую DNS failover (если primary DNS down, используется secondary)
• Проверяю DNS cache (performance)
• Тестирую на разных DNS providers (Google 8.8.8.8, Cloudflare 1.1.1.1)

Вызов, который встретил: На staging environment изменили IP, но DNS не обновился. Приложение не могло подключиться. Решение: flush DNS cache.

SMTP / POP3 / IMAP

Email protocols:

SMTP (Simple Mail Transfer Protocol):

• Port: 25, 465 (TLS), 587 (TLS)
• Отправка emails

POP3 (Post Office Protocol):

• Port: 110, 995 (TLS)
• Получение emails (downloads and deletes)

IMAP (Internet Message Access Protocol):

• Port: 143, 993 (TLS)
• Получение emails (keeps on server)
• Better для multiple devices

При тестировании email functionality:

• Проверяю, что email отправляется
• Проверяю email content (subject, body, attachments)
• Проверяю delivery time
• Тестирую email validation (valid email format)
• Проверяю unsubscribe links

MQTT (Message Queuing Telemetry Transport)

Использование:

• IoT devices
• Lightweight messaging
• Publish-subscribe pattern

Характеристики:

• Low bandwidth
• Low power consumption
• Reliable message delivery

При тестировании IoT:

• Проверяю message publish
• Проверяю message subscribe
• Тестирую QoS levels (0, 1, 2)
• Проверяю на unstable networks

Пример: Тестировал smart home app. MQTT loss rate < 0.1% even на 4G сети. Critical для reliability.

SSH (Secure Shell)

Использование:

• Remote server access
• Secure command execution
• File transfer (SFTP)
• Port forwarding

При тестировании:

• Проверяю SSH access
• Проверяю public key authentication
• Тестирую SSH tunneling
• Проверяю connection timeout'ы

Comparison таблица

Мой опыт тестирования протоколов

Network simulation tools которые использую

Charles Proxy:

• Intercept HTTP/HTTPS
• Throttle bandwidth
• Simulate network issues (packet loss, latency)
• View request/response

Wireshark:

• Deep packet inspection
• Analyze TCP/UDP packets
• Debug network issues
• Protocol analysis

Load testing tools:

• JMeter для HTTP load
• Locust для более complex scenarios
• Artillery для performance

Сценарий: Network issue debugging

Проблема: API slow, but CPU/memory normal

Мой процесс:

1. Открываю Charles Proxy
2. Вижу, что requests очень медленные
3. Тестирую на разных networks (WiFi, 4G, throttled)
4. Обнаружу, что на throttled connection (3G) timeout
5. Выясняю, что API не оптимизирован для slow networks
6. Рекомендую: compression, pagination, lazy loading

Заключение

Как QA инженер я должен понимать не только приложение, но и инфраструктуру, на которой оно работает. Knowledge о протоколах передачи данных позволяет мне:

• Тестировать network scenarios
• Debug connectivity issues
• Оптимизировать performance
• Обеспечить security
• Понимать архитектуру

Это не требует быть network инженером, но solid understanding of protocols делает меня лучше QA.