В чем разница между сокетом Unix и сокетом TCP / IP?

Это из этого ответа:

Сокет UNIX представляет собой механизм межпроцессного взаимодействия , который позволяет осуществлять обмен данными между двунаправленных процессов , работающих на одной и той же машине.

Сокеты IP (особенно сокеты TCP / IP) — это механизм, позволяющий осуществлять связь между процессами по сети. В некоторых случаях вы можете использовать сокеты TCP / IP для связи с процессами, запущенными на одном компьютере (с помощью интерфейса обратной связи).

Доменные сокеты UNIX знают, что они выполняются в одной и той же системе, поэтому они могут избежать некоторых проверок и операций (например, маршрутизации); что делает их быстрее и легче, чем IP-сокеты. Поэтому, если вы планируете взаимодействовать с процессами на одном хосте, это лучший вариант, чем IP-сокеты.

Редактирование: Согласно комментарию Нильса Тедтманна : сокеты домена UNIX подчиняются разрешениям файловой системы, в то время как сокеты TCP можно контролировать только на уровне фильтра пакетов.

Вы можете перечислить локальные unix-сокеты своего компьютера с помощью следующей команды:

В чем разница между сокетом Unix и сокетом TCP / IP?

Разъем TCP / IP используется для связи по сетям TCP / IP. Подключенный TCP-сокет идентифицируется по комбинации локального IP-адреса, локального порта, удаленного IP-адреса и удаленного порта. Прослушивающий сокет TCP определяется локальным портом и, возможно, локальным IP. AIUI по крайней мере в сокетах Linux / TCP / IP всегда приводит к генерации и декодированию пакетов TCP / IP, даже если клиент и сервер находятся на одном компьютере.

Сокет домена unix (иногда сокращенный до сокета unix), с другой стороны, работает на одном компьютере. Прослушивающие сокеты живут в иерархии файловой системы, и доступ к ним может контролироваться разрешениями файловой системы.

Кроме того, процесс, принимающий соединение через сокет Unix, может определить идентификатор пользователя процесса, который подключается. Это может избежать необходимости в шаге аутентификации. Вместо того, чтобы генерировать пароль для вашего сервера базы данных и включать его копию в код вашего веб-приложения, вы можете просто сообщить серверу базы данных, что пользователь, выполняющий веб-приложение, имеет доступ к соответствующей учетной записи пользователя в базе данных.

TCP-сокеты тоже обрабатываются Unix?

TCP-сокеты являются частью спецификации протокола TCP

Спецификации интернет-протокола имеют тенденцию касаться только того, что происходит в сети, спецификация TCP содержит определение Socket, но это определение не совпадает с тем, как термин используется в «API сокетов».

«API сокетов», как мы знаем, было введено BSD, но позже было скопировано повсеместно и включено как часть стандарта posix. Основные вещи для сокетов TCP и UDP, как правило, одинаковы для разных платформ, но более сложные вещи и вещи, взаимодействующие с другими частями ОС, различаются, например, в Unix-подобных системах сокет идентифицируется дескриптором файла и может быть прочитанным / записанным файловыми API, это не относится к Windows.

Некоторые расширения API сокетов были задокументированы в rfcs, но эти RFC являются только «информационными».

или любой протокол может использовать IP-сокеты?

Когда приложение явно создает сокет, используя функцию «сокет» (сокеты также создаются функцией accept), он передает три параметра: «домен», «тип» и «протокол». Между ними эти три параметра могут использоваться для выбора множества различных типов сокетов.

• домен выбирает семейство используемых протоколов / адресов, например, AF_INET для ipv4, AF_INET6 для ipv6, AF_Unix для путей файловой системы unix и т. д.
• Тип выбирает семантику связи, основными из которых являются датаграмма и поток, но есть и другие более специализированные типы.
• протокол выбирает протокол для использования, если он установлен в 0, будет использоваться протокол по умолчанию для комбинации Домена и типа.

TCP tuning

Материал из Xgu.ru

Данная страница находится в разработке. Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной.

Если вы считаете, что её стоило бы доработать как можно быстрее, пожалуйста, скажите об этом.

Содержание

[править] TCP Tuning в Linux

There are a lot of differences between Linux version 2.4 and 2.6, so first we’ll cover the tuning issues that are the same in both 2.4 and 2.6. To change TCP settings in, you add the entries below to the file /etc/sysctl.conf, and then run «sysctl -p».

Like all operating systems, the default maximum Linux TCP buffer sizes are way too small. I suggest changing them to the following settings:

Note: you should leave tcp_mem alone. The defaults are fine.

Another thing you can try that may help increase TCP throughput is to increase the size of the interface queue. To do this, do the following:

I’ve seen increases in bandwidth of up to 8x by doing this on some long, fast paths. This is only a good idea for Gigabit Ethernet connected hosts, and may have other side effects such as uneven sharing between multiple streams. Linux 2.4

Starting with Linux 2.4, Linux has implemented a sender-side autotuning mechanism, so that setting the opitimal buffer size on the sender is not needed. This assumes you have set large buffers on the recieve side, as the sending buffer will not grow beyond the size of the recieve buffer.

However, Linux 2.4 has some other strange behavior that one needs to be aware of. For example: The value for ssthresh for a given path is cached in the routing table. This means that if a connection has has a retransmition and reduces its window, then all connections to that host for the next 10 minutes will use a reduced window size, and not even try to increase its window. The only way to disable this behavior is to do the following before all new connections (you must be root):

More information on various tuning parameters for Linux 2.4 are available in the Ipsysctl tutorial . Linux 2.6

Starting in Linux 2.6.7 (and back-ported to 2.4.27), BIC TCP is part of the kernel, and enabled by default. BIC TCP helps recover quickly from packet loss on high-speed WANs, and appears to work quite well. A BIC implementation bug was discovered, but this was fixed in Linux 2.6.11, so you should upgrade to this version or higher.

Linux 2.6 also includes and both send and receiver-side automatic buffer tuning (up to the maximum sizes specified above). There is also a setting to fix the ssthresh caching weirdness described above.

There are a couple additional sysctl settings for 2.6:

Starting with version 2.6.13, Linux supports pluggable congestion control algorithms . The congestion control algorithm used is set using the sysctl variable net.ipv4.tcp_congestion_control, which is set to Reno by default. (Apparently they decided that BIC was not quite ready for prime time.) The current set of congestion control options are:

• reno: Traditional TCP used by almost all other OSes. (default)
• bic: BIC-TCP
• highspeed: HighSpeed TCP: Sally Floyd’s suggested algorithm
• htcp: Hamilton TCP
• hybla: For satellite links
• scalable: Scalable TCP
• vegas: TCP Vegas
• westwood: optimized for lossy networks

For very long fast paths, I suggest trying HTCP or BIC-TCP if Reno is not is not performing as desired. To set this, do the following:

sysctl -w net.ipv4.tcp_congestion_control=htcp

More information on each of these algorithms and some results can be found here.

Note: Linux 2.6.11 and under has a serious problem with certain Gigabit and 10 Gig ethernet drivers and NICs that support «tcp segmentation offload», such as the Intel e1000 and ixgb drivers, the Broadcom tg3, and the s2io 10 GigE drivers. This problem was fixed in version 2.6.12. A workaround for this problem is to use ethtool to disable segmentation offload:

This will reduce your overall performance, but will make TCP over LFNs far more stable.

More information on tuning parameters and defaults for Linux 2.6 are available in the file ip-sysctl.txt, which is part of the 2.6 source distribution.

And finally a warning for both 2.4 and 2.6: for very large BDP paths where the TCP window is > 20 MB, you are likely to hit the Linux SACK implementation problem. If Linux has too many packets in flight when it gets a SACK event, it takes too long to located the SACKed packet, and you get a TCP timeout and CWND goes back to 1 packet. Restricting the TCP buffer size to about 12 MB seems to avoid this problem, but clearly limits your total throughput. Another solution is to disable SACK. Linux 2.2

If you are still running Linux 2.2, upgrade! If this is not possible, add the following to /etc/rc.d/rc.local

[править] TCP Tuning в FreeBSD

Add these to /etc/sysctl.conf and reboot.

kern.ipc.maxsockbuf=16777216 net.inet.tcp.rfc1323=1 net.inet.tcp.sendspace=1048576 net.inet.tcp.recvspace=1048576

For more info see the: FreeBSD Network Tuning Performance Tuning Guide

FreeBSD version before 4.10 don’t have SACK implemented, which limits its throughput considerably compared to other operating systems. You should upgrade to 4.10 or higher.

[править] TCP Tuning в Solaris

For Solaris create a boot script similar to this (e.g.: /etc/rc2.d/S99ndd)

1. !/bin/sh
2. increase max tcp window
3. Rule-of-thumb: max_buf = 2 x cwnd_max (congestion window)

ndd -set /dev/tcp tcp_max_buf 4194304 ndd -set /dev/tcp tcp_cwnd_max 2097152

1. increase DEFAULT tcp window size

ndd -set /dev/tcp tcp_xmit_hiwat 65536 ndd -set /dev/tcp tcp_recv_hiwat 65536

[править] TCP Tuning в Windows

Change the following using the Windows Registry editor:

1. turn on window scale and timestamp option: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323Opts=3
2. set default TCP window size (default = 16KB): HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpWindowSize=131400
3. and maybe set this too: (default = not set): HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\GlobalMaxTcpWindowSize=16777216

The default for Tcp1323 is «No value»; the default behavior is do not initiate options, but if requested provide them.

You can use setsockopt() in your program to set your buffers to any size up to GlobalMaxTcpWindowSize, or you can use TcpWindowSize to set the default send and receive buffers for ALL sockets to this size. Its probably not a good idea to set this too large, but setting it up to 128K should be OK.

More information is available in the following Microsoft Documents:

This article may also be useful:

[править] TCP Tuning в Mac OS X

Mac OSX tuning is similar to FreeBSD.

sysctl -w kern.ipc.maxsockbuf=16777216 sysctl -w net.inet.tcp.sendspace=1048576 sysctl -w net.inet.tcp.recvspace=1048576

Apple also provides a Broadband Tuner patch that does a less agressive version of this for Mac OS X 10.4 and above.

[править] Полезные программы

Some useful Network Measurement Tools

• Iperf : nice tool for measuring end-to-end TCP/UDP performance
• pathrate/pathload : tools to measure available bandwidth and capacity
• pipechar: hop-by-hop bottleneck analysis tool
• UDPmon: Network performance measurement tool
• synack: ping replacement for sites that block ping

Some useful Network Testing Tools

• NDT: Web100 based Network Configuration Tester
• tcpdump: dump all TCP header information for a specified source/destination
• tcptrace: format tcpdump output for analysis using xplot
• NLANR TCP Testrig : Nice wrapper for tcpdump and tcptrace tools

Полезные трюки при работе с netcat

В данной статье я рассмотрю популярную сетевую утилиту netcat и полезные трюки при работе с ней.

Netcat — утилита Unix, позволяющая устанавливать соединения TCP и UDP, принимать оттуда данные и передавать их. Несмотря на свою полезность и простоту, многие не знают способы ее применения и незаслуженно обходят ее стороной.

С помощью данной утилиты можно производить некоторые этапы при проведении тестирования на проникновение. Это может быть полезно, когда на атакованной машине отсутствуют (или привлекут внимание) установленные пакеты, есть ограничения (например IoT/Embedded устройства) и т.д.

Что можно сделать с помощью netcat:

• Сканировать порты;
• Перенаправлять порты;
• Производить сбор баннеров сервисов;
• Слушать порт (биндить для обратного соединения);
• Скачивать и закачивать файлы;
• Выводить содержимое raw HTTP;
• Создать мини-чат.

Вообще с помощью netcat можно заменить часть unix утилит, поэтому этот инструмент можно считать неким комбайном для выполнения тех или иных задач.

Практические примеры

Во многих случаях при необходимости проверки того или иного хоста используют телнет, либо собственные сервисные службы для выявления хоста или баннера. Как нам может помочь netcat:

Проверка наличия открытого TCP-порта 12345

nc: connect to 192.168.1.100 12345 (tcp) failed: Connection refused

Connection to 192.168.1.100 22 port [tcp/ssh] succeeded!
SSH-2.0-OpenSSH

Сканирование TCP-портов с помощью netcat:

При таком сканировании не будет соединение с портом, а только вывод успешного соединения:

nc: connectx to 192.168.1.100 port 20 (tcp) failed: Connection refused
nc: connectx to 192.168.1.100 port 21 (tcp) failed: Connection refused
found 0 associations
found 1 connections:
1: flags=82
outif en0
src 192.168.1.100 port 50168
dst 192.168.1.100 port 22
rank info not available
TCP aux info available
Connection to 192.168.1.100 port 22 [tcp/*] succeeded!
nc: connectx to 192.168.1.100 port 23 (tcp) failed: Connection refused
nc: connectx to 192.168.1.100 port 24 (tcp) failed: Connection refused

Сканирование UDP-портов.

Для сканирования UDP портов с помощью nmap необходимы root привилегии. Если их нет — в этом случае нам тоже может помочь утилита netcat:

Connection to 192.168.1.100 port 5555 [udp/*] succeeded!

Отправка UDP-пакета

Это может быть полезно при взаимодействии с сетевыми устройствами.

Прием данных на UDP-порту и вывод принятых данных

После первого сообщения вывод будет остановлен. Если необходимо принять несколько сообщений, то необходимо использовать while true:

Передача файлов. С помощью netcat можно как получать файлы, так и передавать на удаленный хост:

Netcact в роли простейшего веб-сервера.

Netcat может выполнять роль простейшего веб-сервера для отображения html странички.

C помощью браузера по адресу: http://хост netcat:8888/index.html. Для использования стандартного порта веб-сервера под номером 80 вам придется запустить nc c root привелегиями:

Чат между узлами

На первом узле (192.168.1.100):

После выполнения команд все символы, введенные в окно терминала на любом из узлов появятся в окне терминала другого узла.

Реверс-шелл

С помощью netcat можно организовать удобный реверс-шелл:

Теперь можно соединиться с удаленного узла:

Не стоит опускать руки, если нет тех или иных инструментов, зачастую довольно громоздких, иногда задачу можно решить подручными средствами.