В інтернеті часто можна зустріти заяви, що проксі-сервер служить для прискорення завантаження за рахунок кешування вмісту сторінок, DNS і т.п. Насправді це тільки одне з корисних властивостей проксі-серверів, але не головне і властиве далеко не всім серверам.
У комп'ютерній термінології "проксі" (проксі) - це програма, яка передає запити вашого ПО в Інтернет, отримує відповіді і передає їх назад.
[CUT]
Необхідність в такій програмі зазвичай виникає, якщо з призначеного для користувача місця не можна працювати в Інтернеті безпосередньо, але вихід є на іншому комп'ютері в його локальної мережі. Тоді на цьому іншому комп'ютері ставлять проксі, а софт на всіх інших комп'ютерах мережі налаштовують таким чином, щоб робота велася через нього. Зараз через проксі вміють працювати практично всі більш-менш популярні програми, так чи інакше призначені для роботи з мережею. Таким чином, якщо хоч один комп'ютер в локальній мережі має доступ "зовні", то і всі інші можуть користуватися цим з'єднанням.
Чи можлива така робота без проксі? Так, можлива - колись все так робили. Але така робота вимагає виконання певних додаткових умов і має свої мінуси в порівнянні з використанням проксі.
Які бувають види проксі?
Я перерахував основні, але не всі можливості HTTP-proxy. Але вже одних перерахованих досить щоб переконатися, що без HTTP-proxy в серйозній мережі не обійтися.
FTP-proxy буває двох основних видів залежно від протоколу роботи самого проксі. З ftp-серверами цей проксі, звичайно, завжди працює по протоколу FTP. А ось з клієнтськими програмами - браузерами і ftp-клієнтами (CuteFTP, FAR, і ін.) Проксі може працювати як по FTP, так і по HTTP. Другий спосіб зручніше для браузерів, тому що історично є для них "рідним". Браузер запитує ресурс у проксі, вказуючи протокол цільового сервера в URL - http або ftp. Залежно від цього проксі вибирає протокол роботи з цільовим сервером, а протокол роботи з браузером не змінюється - HTTP. Тому, як правило, функцію роботи з FTP-серверами також вставляють в HTTP-proxy. тобто HTTP-proxy. Опис вище, зазвичай з однаковим успіхом працює як з HTTP, так і з FTP-серверами. Але при "конвертації" протоколів FTP<->HTTP втрачається частина корисних функцій протоколу FTP. Тому спеціалізовані ftp-клієнти воліють і спеціальний проксі, який працює з обома сторонами по FTP. Такий проксі називається FTP-gate, щоб підкреслити відмінність від FTP-proxy в складі HTTP-proxy. Також цей проксі називається і в деяких ftp-клієнтів. Хоча зустрічаються і вносять ще більшу плутанину назви: наприклад, в програмі CuteFTP FTP-gate називають firewall, хоча firewall, в загальному випадку, - це взагалі не проксі, а, фактично, програма зворотного призначення - не для підключення до інтернету, а для ізоляції від нього. FTP-gate підтримують різні способи вказівки в FTP-протоколі цільового сервера, з яким FTP-клієнт хоче працювати, в налаштуванні FTP-клієнтів зазвичай пропонується вибір цього способу.
Socks-proxy. Про цей вид проксі буде вестися окрема розмова, тому що на даний момент це самий "прогресуючий" протокол.
Розроблено він Дейвом Кобласом (Dave Koblas) з компанії SGI. З початку існування протокол пережив кілька великих модифікацій, а на сьогоднішній день "в роботі" перебувають дві версії протоколу: Socks4 і Socks5. Не дивлячись на те, що Socks5 більш "просунутий", зараз з однаковою мірою поширені сервера як з підтримкою старої, так і нової версії. Протокол є транслятор (щось на зразок проксі сервера), але на відміну від звичайних проксі Socks-клієнт "сидить" між прикладним і транспортним рівнем в мережевий моделі, а Socks-сервер перебувати на прикладному рівні. Це означає, що такий сервер не прив'язаний більше до протоколів високого рівня. Сам протокол розроблений для того, щоб програми, що працюють на основі tcp і udp, могли використовувати ресурси мережі, доступ до яких обмежений архітектурою або настройками (наприклад, доступ до ресурсів Інтернету з локальної мережі для додатків, у яких взагалі не передбачена робота з використанням проксі ).