Відмінності між версіями «5 Конфігурування кешуючих серверів»
(Створена сторінка: Інтернет-користувачі спрямовують свої запити до веб-серверів по всьому інтернету. Кешу...) |
Xphlash (Обговорення • внесок) |
||
| (Одна проміжна версія одного користувача не показана) | |||
| Рядок 1: | Рядок 1: | ||
| − | Інтернет-користувачі спрямовують свої запити до веб-серверів по всьому інтернету. Кешування сервера повинно виступати в якості сервера веб-проксі | + | Інтернет-користувачі спрямовують свої запити до веб-серверів по всьому інтернету. Кешування сервера повинно виступати в якості сервера веб-проксі. Після того, як проксі-сервер отримує запити на веб об'єкти, або обслуговує запити, або пересилає їх на сервер-походження (веб-сервер, який містить оригінальну копію запитуваної інформації). |
| − | + | Проксі сервери підтримують явні кешування проксі-серверів, в яких клієнтське програмне забезпечення користувача повинно бути налаштовано на відправку запитів безпосередньо через алгоритм роботи проксі-сервер: | |
| − | + | #Проксі отримує запит від клієнта на веб-об'єкт. | |
| − | + | #Використання адреси об'єкта, проксі намагається знайти необхідний об'єкт в базі даних (кеш). | |
| − | + | #Якщо об'єкт знаходиться в кеші, то проксі перевіряє, чи об'єкт є достатньо свіжим, щоб його використовувати. Якщо він свіжий, то проксі обслуговує його клієнта. | |
| − | + | #Якщо дані в кеші, застарілі, то проксі підключається до сервера походження і перевіряє, чи є відновлений об'єкт. Якщо такий об’єкт є, то проксі негайно посилає збережену копію клієнту. | |
| − | + | #Якщо об'єкт не знаходиться в кеш-пам'яті (кеші), або якщо сервер вказує на збережену копію і більше не діє, то проксі отримує об'єкт з вихідного сервера. Потім об'єкт одночасно передається клієнтові і проксі локального кешу. | |
| − | + | Наступні запити на об'єкт можуть бути подані швидше, тому що об'єкт витягується безпосередньо з кешу. Кешування, як правило, більш складні. Traffic Server забезпечує свіжість, служить як правильний заступник HTTP, і розглядає запити на об'єкти, які не можуть, або не повинні бути в кеші. Кешуючі проксі, як зазначено в їхній назві, є проксі-серверами, які налаштовані на повторне використання кеш-образів контенту, коли це можливо. Коли кешу частина контенту недоступна, то проводиться її вибірка та використання в контенті, а також спроба її кешування. Найбільш важливим аспектом для кешуючих проксі є необхідність забезпечення того, що кешуючі проксі кешують тільки те, що насправді можна кешувати. Динамічно, регулярно змінювати контент не найкращий вибір для кешування, так, як це може вплинути на стабільність програми, заснованої на цьому контенті. У разі HTTP-контенту заголовки HTTP відображають можливість кешування контенту за допомогою покажчиків "cache". У більшості випадків, проксі конфігуруються також для роботи в якості кешуючих проксі. Це явище використовується настільки часто, що компанія IBM включила це в назву компонента свого Edge Server: IBM Caching Proxy. Проксі-сервер (відомий також як шлюз додатків) являє собою додаток, що виступає для трафіку в якості посередника між надійною мережею і ненадійною мережею. Це не знімає необхідності застосування браузера для управління трафіком на IP-рівні, щоб не передбачати наявність браузера прикладного рівня. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | Наступні запити на об'єкт | + | |
| − | + | ||
| − | У більшості випадків | + | |
Поточна версія на 01:29, 20 червня 2014
Інтернет-користувачі спрямовують свої запити до веб-серверів по всьому інтернету. Кешування сервера повинно виступати в якості сервера веб-проксі. Після того, як проксі-сервер отримує запити на веб об'єкти, або обслуговує запити, або пересилає їх на сервер-походження (веб-сервер, який містить оригінальну копію запитуваної інформації). Проксі сервери підтримують явні кешування проксі-серверів, в яких клієнтське програмне забезпечення користувача повинно бути налаштовано на відправку запитів безпосередньо через алгоритм роботи проксі-сервер:
- Проксі отримує запит від клієнта на веб-об'єкт.
- Використання адреси об'єкта, проксі намагається знайти необхідний об'єкт в базі даних (кеш).
- Якщо об'єкт знаходиться в кеші, то проксі перевіряє, чи об'єкт є достатньо свіжим, щоб його використовувати. Якщо він свіжий, то проксі обслуговує його клієнта.
- Якщо дані в кеші, застарілі, то проксі підключається до сервера походження і перевіряє, чи є відновлений об'єкт. Якщо такий об’єкт є, то проксі негайно посилає збережену копію клієнту.
- Якщо об'єкт не знаходиться в кеш-пам'яті (кеші), або якщо сервер вказує на збережену копію і більше не діє, то проксі отримує об'єкт з вихідного сервера. Потім об'єкт одночасно передається клієнтові і проксі локального кешу.
Наступні запити на об'єкт можуть бути подані швидше, тому що об'єкт витягується безпосередньо з кешу. Кешування, як правило, більш складні. Traffic Server забезпечує свіжість, служить як правильний заступник HTTP, і розглядає запити на об'єкти, які не можуть, або не повинні бути в кеші. Кешуючі проксі, як зазначено в їхній назві, є проксі-серверами, які налаштовані на повторне використання кеш-образів контенту, коли це можливо. Коли кешу частина контенту недоступна, то проводиться її вибірка та використання в контенті, а також спроба її кешування. Найбільш важливим аспектом для кешуючих проксі є необхідність забезпечення того, що кешуючі проксі кешують тільки те, що насправді можна кешувати. Динамічно, регулярно змінювати контент не найкращий вибір для кешування, так, як це може вплинути на стабільність програми, заснованої на цьому контенті. У разі HTTP-контенту заголовки HTTP відображають можливість кешування контенту за допомогою покажчиків "cache". У більшості випадків, проксі конфігуруються також для роботи в якості кешуючих проксі. Це явище використовується настільки часто, що компанія IBM включила це в назву компонента свого Edge Server: IBM Caching Proxy. Проксі-сервер (відомий також як шлюз додатків) являє собою додаток, що виступає для трафіку в якості посередника між надійною мережею і ненадійною мережею. Це не знімає необхідності застосування браузера для управління трафіком на IP-рівні, щоб не передбачати наявність браузера прикладного рівня.
