Отличная статья Джереми Московица о Group Policy в Windows 7 и Windows Server 2008 на родном всем компьютерщикам английском языке.
What’s New in Group Policy for Windows 7 and Windows Server 2008 R2
Jeremy Moskowitz
At a Glance:
* Updated RSAT filters
* Automated GPO handling with Windows PowerShell
* Tabless interface for ADM and ADMX
* Built-in Starter GPOs and new policy settings
Contents
Updated Group Policy Core Features
Beyond the Core Features
Learn More
I get e-mail almost every day from people asking me, "What's coming for Group Policy in the new version of Windows?" In this question, I can feel an eagerness to know what the new features and changes will mean for IT professionals.
I know that change can sometimes be stressful, but I can say confidently that the news is all good: Some powerful, neat Group Policy changes are included in Windows 7 and Windows Server 2008 R2, but nothing too radical or different. IT professionals will benefit from some updates, some new features and some user interface tweaks, for example, but without the headaches associated with steep learning curves.
The Group Policy changes can be divided into two broad categories. First are the items the Group Policy team delivers: core functionality, including the Group Policy engine and new and updated features in the Group Policy editing system (Group Policy Management Console, or GPMC, and Group Policy Management Editor, or GPME). Second are items that other teams provide to manage their components using Group Policy: updated policy settings and feature controls inside GPME that we all use to manage the new and updated functions on our target machines. In this article, I cover both kinds of changes.
Updated Group Policy Core Features
For Windows 7 and Windows Server 2008 R2, the Group Policy team has come through with a smorgasbord of features and updates. Here's the nonscientific breakdown of what is delivered in the most recent update of Windows: one big fix, one big update, one big new feature, one big user interface change and one big in-the-box addition.
The Big Fix: Updated Filters
The updated filters in the updated GPMC (available for Windows 7 and Windows Server 2008 R2) are welcome changes. The fixes squash a bug that's been around since Windows Vista shipped. In Figure 1, you can see one of my favorite features that's been available since the updated GPMC, contained within the Remote Server Administration Toolkit (RSAT): the Filter Options dialog box.
Figure 1 Filter Options dialog box. (Click the image for a larger view)
RSAT's job is simple: to let you use a Vista (or later) machine to control various aspects of your network from the machine you use and to provide the tools you need to do so, including the updated GPMC. This updated GPMC has some neat features; one of them is the ability to use filters to define the criteria you want to use to find just the Administrative Templates Group Policy settings you want. The problem was that when Vista and its corresponding RSAT came out, the filters didn't work, a bug that plagued many administrators.
Let me explain the bug in a little more detail. Figure 1 shows the Enable Requirements Filters section of the Filters dialog box. The goal of this section is simple: to help you figure out which Administrative Templates policy settings are valid for specific operating systems.
One mode within Enable Requirements Filters is "Include settings that match all of the selected platforms." The other is "Include settings that match any of the selected platforms. At first glance, the two modes seem very similar. But the difference between "all" and "any" is substantial. Here is what each mode is supposed to do once you select it and specify some criteria:
* "Include settings that match all of the selected platforms" should show policy settings that are valid only on the types of machines specified. So if you select Windows XP Service Pack (SP) 2 and Vista, the result should be policy settings that work only on Windows XP SP2 and Vista.
* "Include settings that match any of the selected platforms" should show settings that apply to any of the selected operating systems. So if you select both Windows XP SP2 and Vista, all settings that apply to Windows XP SP2 and all settings that apply to Vista should be displayed.
These filters are both as useful as they sound. The only problem is that with the Vista and Windows Server 2008 version of RSAT, neither of them worked properly. If you selected "Include settings that match all of the selected platforms," the result was often a mere fraction of valid settings that were actually applicable to target machines. And if you selected "Include settings that match any of the selected platforms," no results were ever displayed.
According to my friends in the Group Policy team, this fix should be part of the final downloadable version of RSAT for Windows 7 and the in-the-box RSAT for Windows Server 2008 R2.
The Big Update: Deploying Windows PowerShell Scripts to Target Machines
Unless you're living under a rock, you know that Windows PowerShell is gaining popularity with system administrators. But one issue has blocked some administrators from adopting PowerShell. There hasn't been a simple way for them to leverage their newfound PowerShell muscle over an area in which they need the most control: user and computer scripts.
The RSAT in Windows 7 and Windows Server 2008 R2 allows administrators to specify PowerShell scripts as either logon or logoff scripts (for the user) and startup or shutdown scripts (for the computer). Figure 2 shows the Startup Properties dialog box in the GPME, in which the administrator can specify the order in which PowerShell scripts run and also which type of scripts should run first: PowerShell scripts or the non-PowerShell scripts (which are not shown but are located within the Scripts tab in the Startup Properties dialog box).
Figure 2 Windows PowerShell Scripts tab in the Startup Properties dialog box. (Click the image for a larger view)
To use this feature, you need to create or edit your Group Policy Objects (GPOs) from a Windows 7 or Windows Server 2008 R2 machine with the corresponding RSAT tools (which contain an updated GPMC to support this new functionality). In addition, the target machine must be Windows 7 or Windows Server 2008 R2 for the PowerShell scripts to run. Older machines (even with PowerShell loaded) are not valid targets and do not run PowerShell logon, logoff, startup or shutdown scripts. Some third-party solutions that can deploy PowerShell scripts to non-Windows 7 machines are available if you need this capability.
The Big Feature: Manipulating Registry Settings with PowerShell Cmdlets
Lots of system administrators like to automate their world. This a good thing. Indeed, you can think of leveraging Group Policy in your environment as the mass automation of your client machines (so you don't have to run around and push buttons). To take your administration to the next level, you might want to automate the handling of your GPOs themselves.
Some administrators have leveraged the existing Group Policy GPMC sample scripts to automate key Group Policy tasks.
Windows 7 and Windows Server 2008 R2 allow you to use PowerShell to perform many of these functions. What was possible in the GPMC sample scripts is now possible using PowerShell: creating, linking, renaming, backing up, copying and deleting GPOs as well as much more.
The ability to configure the contents of a GPO using a scriptable method, however, is totally new and now available only when you use PowerShell as your scripting method. Before you get too excited, I should mention that not all 39 areas of Group Policy are scriptable. Indeed, only two are: Registry Policy and Registry Preference. Even so, it's a terrific start.
In Figure 3, you can see how I'm using the built-in PowerShell in Windows 7 to first install the Group Policy-specific cmdlets using the cmdlet import-module grouppolicy and then create a new GPO with the new-gpo cmdlet.
Figure 3 Creating a new GPO using Group Policy cmdlets built into Windows 7. (Click the image for a larger view)
The Group Policy team's blog has an array of items regarding Windows PowerShell integration. You can view all of them at one glance by checking out the the Group Policy Team Blog.
The Big User Interface Change: Updated ADM and ADMX User Interface
One of the most striking Group Policy changes is in the Administrative Templates section of the GPME.
A new "tabless" interface, shown in Figure 4, puts all the content you need for creating new or manipulating existing policy settings in a one-stop-shop page.
Figure 4 Windows Firewall: Allow ICMP Exceptions dialog box. (Click the image for a larger view)
Administrators can now configure a policy setting as Not Configured, Enabled or Disabled, make comments about a policy setting, see the Supported On information, view the Help (Explaintext), and manipulate any configurable settings within Options.
The goal of this change is to make the policy-setting experience more intuitive, integrate help and take away all the tabs so administrators don't have to click from place to place anymore.
The Big In-the-Box Addition: Built-in Starter GPOs
The ability to create and use Starter GPOs first became available in the Vista version of the GPMC. The idea behind a Starter GPO is that an administrator can create a starting point for other administrators to use when creating their GPOs. The fundamental architecture and functionality hasn't changed much in this new update, but one new distinction is notable.
Specifically, when you use a Windows 7 or Windows Server 2008 R2 machine to create the Starter GPO's container, the container is automatically populated with some built-in Starter GPOs. These Starter GPOs follow Microsoft best practices and map to the Windows Server 2008 Security Guide. For example, one of these built-in Starter GPOs is for an average Enterprise Client (EC) and another, with a more locked-down approach, is called Specialized Security Limited Functionality (SSLF).
Windows 7 and Windows Server 2008 R2 include Starter GPOs for both the user and computer sides. These Microsoft-created Starter GPOs are also available (in slightly older form) for Vista and Windows XP SP2.
Beyond the Core Features
Now let's talk about some of the areas of additional control you get when you're working with Windows 7 or Windows Server 2008 R2 as a client. And when I say "client" here, I mean "the computer receiving Group Policy directives" (even if it's a Windows Server 2008 R2 machine).
One great addition is about 300 new policy settings, of which 90 or so are meant just for Internet Explorer 8 (which is available for Vista and Windows XP machines). Other changes include new and updated settings management for BitLocker, BitLocker To Go, an updated taskbar, Remote Desktop Services (which used to be called Terminal Services), BranchCache, Windows Remote Management (WinRM) and heaps of other controls. I won't be able to explore all the new controls in this article, but I will give you an up close and personal look at some of my favorites.
Updated Group Policy Preferences for Power Options
One of the key reasons IT geeks fall in love with Group Policy is the amount of control it allows them to exert on desktops. When the main focus of Group Policy is settings delivery, however, these control-freak IT geeks can sometimes have difficulty explaining to managers why Group Policy has value in raw "dollars and sense." In one area of Group Policy, though, real cost savings can be promised (if utilized properly): power settings.
By properly configuring the power settings of desktops and laptops, IT administrators can usually save their companies thousands of dollars annually. Group Policy makes such configuring easy.
Figure 5 shows the power options available in the Windows 7 (and Windows Server 2008 R2) GPMC.
Figure 5 New Power Plan (Windows Vista and later) Properties dialog box. (Click the image for a larger view)
Look closely at the title of the dialog box in Figure 5. You'll notice that it says New Power Plan (Vista and later) Properties. That is to say, these settings are valid for both Vista and Windows 7. Here's the caveat: Windows 7 and Windows Server 2008 R2 client machines will know what to do with these directives right away; Vista will not. Vista will simply ignore the directives (even though the feature is clearly labeled as Windows Vista and later). That's because Vista needs a soon-to-be-released update to the client-side extensions of its underlying Group Policy Preferences. Once available and applied, Vista machines will embrace these newly available directives.
Updated Group Policy Preferences for Scheduled Tasks
Similar to the updated Power Plan settings just mentioned is additional task-scheduling functionality within the GPMC in Windows 7 and Windows Server 2008 R2. Figure 6 shows the new options for scheduling tasks: Scheduled Task (Windows Vista and later) and Immediate Task (Windows Vista and later).
Figure 6 New GPMC task-scheduling options in Windows 7. (Click the image for a larger view)
Like the Power Plan settings, Windows 7 computers are ready to use these settings. Vista machines will need to wait for an update that will allow them to utilize these settings.
Updated Software Restriction Policies: AppLocker
The under-the-hood name for AppLocker is Software Restriction Policies version 2, or SRPv2. In the Group Policy interface (and in the documentation), however, you'll see this new feature called simply AppLocker.
Briefly, the goal of AppLocker is to help modern IT organizations dictate which software should and shouldn't run on their Windows 7 (and later) machines. The original Software Restriction Policies (SRP) did a decent job, but AppLocker takes software restrictions to the next level. One key new AppLocker ability is to allow or restrict software based on the software's publisher. To take advantage of this new feature, the software you want to allow or restrict must be digitally signed (for more information on AppLocker, see Greg Shields' Geek of All Trades column, "AppLocker: IT's First Panacea?").
Then, using the Create Executable Rules Dialog Box, you set up rules for various publishers. For example, you can create a rule specifying that it's OK to run Adobe Reader as long as the version is 9.0 or higher. You can move up the vertical slider to specify that all versions, filenames, and/or products or publishers can be valid on target systems. Or you can be specific with the Use custom values check box.
Learn More
As you can see, Windows 7 and Windows Server 2008 R2 bring a lot of enhancements to Group Policy. From the 300 new policy settings, to the two updated Group Policy Preferences, to the integration of Windows PowerShell—there's a lot to love. To learn more about Group Policy in Windows 7 and Windows Server 2008 R2, you can check out the Group Policy team blog, as well as my blog and training resources at GPanswers.com.
Jeremy Moskowitz is a Group Policy MVP. He runs GPanswers.com, a community forum for Group Policy, and trains hundreds of administrators each year in his Group Policy Master Classes. Jeremy is also founder of PolicyPak Software (PolicyPak.com), which makes an innovative add-on to control third-party applications using Group Policy.
Оригинал статьи (с картинками) на сайте Тechnet:
Windows 7: What’s New in Group Policy for Windows 7 and Windows Server 2008 R2
«КАМТЕC» - профессиональное обучение компьютерным специальностям
четверг, 8 октября 2009 г.
Мировой любовник
Тут я решил закинуть статью не совсем на компьютерную тему, даже, можно сказать на совсем не компьютерную...
А кто сказал, что мы обязаны ограничиваться только компьютерной тематикой, ведь ничто человеческое...
Итак, женский взгляд на мужчин разных стран...
Женщины поделились своими впечатлениями от любовников в разных странах - в ходе интернет-опроса женщины из 20 стран назвали испанцев лучшими любовниками в мире, в то время как немцы понравились им меньше всех из-за неприятного запаха, русских они сочли слишком волосатыми, а американцев - слишком грубыми.
Исследование провел сайт OnePoll, в нем приняли участие 15 тыс. женщин из 20 государств, все «опытные путешественницы». Женщин попросили оценить, насколько хороши мужчины из различных стран в постели, и обосновать свои ответы.
Второе место с конца в списке заняли англичане, поскольку они «оставляют всю работу женщинами». Шведские мужчины справляются со своими обязанностями в постели слишком быстро, голландцы и американцы слишком властно и грубо ведут себя во время секса.
Как и следовало ожидать, лучшие любовники живут в южных странах. Первое место досталось Испании, за ней следуют Бразилия, Италия и Франция. В то же время греки и турки вошли в десятку худших любовников.
Худшие любовники мира:
1. Немцы (слишком неопрятные)
2. Англичане (слишком ленивые)
3. Шведы (слишком быстрые)
4. Голландцы (слишком властные)
5. Американцы (слишком грубые)
6. Греки (слишком слащавые)
7. Валлийцы (слишком эгоистичные)
8. Шотландцы (слишком шумные)
9. Турки (слишком потные)
10. Русские (слишком волосатые)
Лучшие любовники мира:
1. Испания
2. Бразилия
3. Италия
4. Франция
5. Ирландия
6. ЮАР
7. Австралия
8. Новая Зеландия
9. Дания
10. Канада
«Эти результаты открывают глаза тысячам мужчин по всему миру, а путешествующие женщины могут оценить потенциал новых любовников, взглянув на эти результаты», - считает представитель OnePoll.
Аналогичный опрос в 2007 году был проведен сайтом WAYN среди женщин из 50 стран. Немцы и тогда были названы наихудшими любовниками, однако женщин раздражала их эгоистичность, а не неряшливость, в то время, как русские уже тогда вызывали недовольство из-за волосяного покрова. Между тем, испанцы два года назад занимали только шестое место в списке лучших любовников, а лидировали итальянцы.
А кто сказал, что мы обязаны ограничиваться только компьютерной тематикой, ведь ничто человеческое...
Итак, женский взгляд на мужчин разных стран...
Женщины поделились своими впечатлениями от любовников в разных странах - в ходе интернет-опроса женщины из 20 стран назвали испанцев лучшими любовниками в мире, в то время как немцы понравились им меньше всех из-за неприятного запаха, русских они сочли слишком волосатыми, а американцев - слишком грубыми.
Исследование провел сайт OnePoll, в нем приняли участие 15 тыс. женщин из 20 государств, все «опытные путешественницы». Женщин попросили оценить, насколько хороши мужчины из различных стран в постели, и обосновать свои ответы.
Второе место с конца в списке заняли англичане, поскольку они «оставляют всю работу женщинами». Шведские мужчины справляются со своими обязанностями в постели слишком быстро, голландцы и американцы слишком властно и грубо ведут себя во время секса.
Как и следовало ожидать, лучшие любовники живут в южных странах. Первое место досталось Испании, за ней следуют Бразилия, Италия и Франция. В то же время греки и турки вошли в десятку худших любовников.
Худшие любовники мира:
1. Немцы (слишком неопрятные)
2. Англичане (слишком ленивые)
3. Шведы (слишком быстрые)
4. Голландцы (слишком властные)
5. Американцы (слишком грубые)
6. Греки (слишком слащавые)
7. Валлийцы (слишком эгоистичные)
8. Шотландцы (слишком шумные)
9. Турки (слишком потные)
10. Русские (слишком волосатые)
Лучшие любовники мира:
1. Испания
2. Бразилия
3. Италия
4. Франция
5. Ирландия
6. ЮАР
7. Австралия
8. Новая Зеландия
9. Дания
10. Канада
«Эти результаты открывают глаза тысячам мужчин по всему миру, а путешествующие женщины могут оценить потенциал новых любовников, взглянув на эти результаты», - считает представитель OnePoll.
Аналогичный опрос в 2007 году был проведен сайтом WAYN среди женщин из 50 стран. Немцы и тогда были названы наихудшими любовниками, однако женщин раздражала их эгоистичность, а не неряшливость, в то время, как русские уже тогда вызывали недовольство из-за волосяного покрова. Между тем, испанцы два года назад занимали только шестое место в списке лучших любовников, а лидировали итальянцы.
среда, 7 октября 2009 г.
Как присоединить XenServer к Windows Storage Server 2003 R2 (на основе HP AiO) при помощи iSCSI
Дано:
XenServer 5.5 (HP Blade Server c460 G6)
Windows Storage Server 2003 R2 (HP Blade Server)
В качестве коробочки используется HP BladeSystem c7000 Enclosure.
Нужно:
Присоединить XenServer к Windows Storage Server 2003 R2 (на основе HP AiO) при помощи iSCSI.
Порядок действий:
1. Сначала на Storage создается iSCSI Target. При этом указываются параметры компьютера-источника (XenServer).
2. Затем на Storage к iSCSI Target присоединяется (или создается специально) виртуальный диск (или диски).
3. На компьютере-источнике (XenServer) создается новый iSCSI Storage Repository при помощи программы управления Citrix XenCenter или же с самого XenServer (второе менее удобно, но возможно).
4. Ставим виртуальные машины на новом репозитории.
А вот статья Александр Самойленко на аналогичную тему:
Как поднять программный iSCSI Target на Windows 2003 Server для ESX
XenServer 5.5 (HP Blade Server c460 G6)
Windows Storage Server 2003 R2 (HP Blade Server)
В качестве коробочки используется HP BladeSystem c7000 Enclosure.
Нужно:
Присоединить XenServer к Windows Storage Server 2003 R2 (на основе HP AiO) при помощи iSCSI.
Порядок действий:
1. Сначала на Storage создается iSCSI Target. При этом указываются параметры компьютера-источника (XenServer).
2. Затем на Storage к iSCSI Target присоединяется (или создается специально) виртуальный диск (или диски).
3. На компьютере-источнике (XenServer) создается новый iSCSI Storage Repository при помощи программы управления Citrix XenCenter или же с самого XenServer (второе менее удобно, но возможно).
4. Ставим виртуальные машины на новом репозитории.
А вот статья Александр Самойленко на аналогичную тему:
Как поднять программный iSCSI Target на Windows 2003 Server для ESX
Удаление Child Domain при помощи NTDSutil
Сегодня получилось наконец избавиться от "Child Domain" при помощи NTDSutil.
Это было опробовано давно и безрезультатно, но большой нужды в этом не было, разве что для порядка,
т.к. в диалоговом окне Log On можно было увидеть Domain TEST в списке доступных домейнов .
Сегодня была предпринята праздничная (Суккот) попытка установить пробный Windows Server 2008 R2 HTC в существующий DOMAIN и поднять его роль до DC.
Пришлось поэтому пошевелить извилинами.
Нужно было при помощи ADPREP 2008 обновить схему AD (/forestprep, /domainprep, /gcprep), т.к. без этого нельзя поднимать новый 2008 сервер до DC.
В процессе обновления были выявлены различные ошибки, один из DC (TACH2003FS) перестал видеть главный DC (TACH2003).
Т.е. он его видел, но средства управления – нет. Пришлось его опустить до Member Server и поднять другой сервер в качестве DC (SQL2005AB).
Опускание тоже прошло не без проблем. Пришлось заняться репликацией (replmon, repadmin).
Кроме того, при попытке поднять Server 2008 R2 на уровень DC был обнаружен (в очередной раз) несуществующий,
но все еще неудаленный "Child Domain" под именем TEST, оставшийся после каких-то экспериментов
(дополнительный Domain был виден каждый раз в списке Domains при Log On).
В NTDSutil (главном средстве удаления остатков неудачных экспериментов с Active Directory) команда "connect to server primary-dc" давала ошибку. В конце концов, оказалось, что вместо "primary-dc" можно писать "localhost" (ошибкой нужно будет заняться потом отдельно).
Команда "list domain" показала "Child Domain" TEST и нужно было сделать QUIT и затем "remove selected domain". Все в итоге сработало!
Если будут интересны подробности, пишите, опишу все Step-by-Step.
Это было опробовано давно и безрезультатно, но большой нужды в этом не было, разве что для порядка,
т.к. в диалоговом окне Log On можно было увидеть Domain TEST в списке доступных домейнов .
Сегодня была предпринята праздничная (Суккот) попытка установить пробный Windows Server 2008 R2 HTC в существующий DOMAIN и поднять его роль до DC.
Пришлось поэтому пошевелить извилинами.
Нужно было при помощи ADPREP 2008 обновить схему AD (/forestprep, /domainprep, /gcprep), т.к. без этого нельзя поднимать новый 2008 сервер до DC.
В процессе обновления были выявлены различные ошибки, один из DC (TACH2003FS) перестал видеть главный DC (TACH2003).
Т.е. он его видел, но средства управления – нет. Пришлось его опустить до Member Server и поднять другой сервер в качестве DC (SQL2005AB).
Опускание тоже прошло не без проблем. Пришлось заняться репликацией (replmon, repadmin).
Кроме того, при попытке поднять Server 2008 R2 на уровень DC был обнаружен (в очередной раз) несуществующий,
но все еще неудаленный "Child Domain" под именем TEST, оставшийся после каких-то экспериментов
(дополнительный Domain был виден каждый раз в списке Domains при Log On).
В NTDSutil (главном средстве удаления остатков неудачных экспериментов с Active Directory) команда "connect to server primary-dc" давала ошибку. В конце концов, оказалось, что вместо "primary-dc" можно писать "localhost" (ошибкой нужно будет заняться потом отдельно).
Команда "list domain" показала "Child Domain" TEST и нужно было сделать QUIT и затем "remove selected domain". Все в итоге сработало!
Если будут интересны подробности, пишите, опишу все Step-by-Step.
пятница, 2 октября 2009 г.
Создание FTP-сайта на основе IIS 6.0
Здесь приведена схема создания реального FTP-сайта на основе IIS 6.0.
Условия были следующие:
Существует некий FTP-сервер, одна "нога" которого через ADSL-роутер с постоянным внешним IP-адресом подсоединяется к Internet, а другая имеет выход в локальную сеть с доменом Active Directory 2003.
При этом сам FTP-сервер членом домена не является (слава Богу).
Задачи стояли такие:
a. Нужно обеспечить передачу больших видео-файлов в обе стороны,
при этом максимально облегчить работу и сократить ее объем.
Т.е., желательно не создавать в IIS виртуальные директории для каждого пользователя.
От создания папок в файловой системе, конечно, было не уйти.
Здесь оказалось, что имеет значение имя папки, создаваемой под корнем FTP. Она должна иметь специфическое имя "LocalUser".
Так же, при создании сайта нужно использовать функцию изоляции пользователей.
b. В дополнение нужно создать Публичный сайт, к которому можно подсоединяться Анонимным пользователем.
Здесь имя папки значения не имело, лишь бы путь был правильно указан в свойствах FTP-сайта.
c. Еще одна дополнительная задача - возможность для администратора подсоединяться из Internet через FTP-сервер к "shared folders" на файл-сервере домена.
Здесь трудность была в том, каким пользователем "проскочить" в домен, ведь наш FTP, вспомним, не в домене, а использовать одинакового пользователя для входа на FTP и в домен (т.е. раскрывать его имя и давать возможность подобрать пароль) совсем, как-то, не безопасно. Т.е., аутентифицироваться на сервере FTP нужно одним пользователем, а доступ к "shared folders" (автоматически и прозрачно для пользователя) получать другим.
Решение было в том, чтобы создать пользователей с одинаковыми именем и паролем как на сервере FTP, так и в домене Active Directory, а затем указать пользователя с сервера FTP в свойствах соответствующего FTP-сайта. При этом входящий пользователь не имеет понятия, через какого пользователя он на самом деле подсоединяется к "shared folders" (и, значит, не может узнать имя и пароль пользователя домена).
Можно, правда, создать кучу соответствующих пользователей как на сервере FTP и в домене Active Directory, но зачем попу гармонь ? Я хочу сказать, что это:
1. небезопасно
2. засоряет Active Directory
3. засоряет FTP-сервер
d. Также надо было настроить свойства ADSL-роутера так, что бы по разным портам подсоединяться к разным серверам.
Далее следует пошаговое обьяснение процесса создания FTP-сервера.
(продолжение следует)
Условия были следующие:
Существует некий FTP-сервер, одна "нога" которого через ADSL-роутер с постоянным внешним IP-адресом подсоединяется к Internet, а другая имеет выход в локальную сеть с доменом Active Directory 2003.
При этом сам FTP-сервер членом домена не является (слава Богу).
Задачи стояли такие:
a. Нужно обеспечить передачу больших видео-файлов в обе стороны,
при этом максимально облегчить работу и сократить ее объем.
Т.е., желательно не создавать в IIS виртуальные директории для каждого пользователя.
От создания папок в файловой системе, конечно, было не уйти.
Здесь оказалось, что имеет значение имя папки, создаваемой под корнем FTP. Она должна иметь специфическое имя "LocalUser".
Так же, при создании сайта нужно использовать функцию изоляции пользователей.
b. В дополнение нужно создать Публичный сайт, к которому можно подсоединяться Анонимным пользователем.
Здесь имя папки значения не имело, лишь бы путь был правильно указан в свойствах FTP-сайта.
c. Еще одна дополнительная задача - возможность для администратора подсоединяться из Internet через FTP-сервер к "shared folders" на файл-сервере домена.
Здесь трудность была в том, каким пользователем "проскочить" в домен, ведь наш FTP, вспомним, не в домене, а использовать одинакового пользователя для входа на FTP и в домен (т.е. раскрывать его имя и давать возможность подобрать пароль) совсем, как-то, не безопасно. Т.е., аутентифицироваться на сервере FTP нужно одним пользователем, а доступ к "shared folders" (автоматически и прозрачно для пользователя) получать другим.
Решение было в том, чтобы создать пользователей с одинаковыми именем и паролем как на сервере FTP, так и в домене Active Directory, а затем указать пользователя с сервера FTP в свойствах соответствующего FTP-сайта. При этом входящий пользователь не имеет понятия, через какого пользователя он на самом деле подсоединяется к "shared folders" (и, значит, не может узнать имя и пароль пользователя домена).
Можно, правда, создать кучу соответствующих пользователей как на сервере FTP и в домене Active Directory, но зачем попу гармонь ? Я хочу сказать, что это:
1. небезопасно
2. засоряет Active Directory
3. засоряет FTP-сервер
d. Также надо было настроить свойства ADSL-роутера так, что бы по разным портам подсоединяться к разным серверам.
Далее следует пошаговое обьяснение процесса создания FTP-сервера.
(продолжение следует)
четверг, 24 сентября 2009 г.
Windows Server 2008 R2 - Supported upgrade paths
Взято из форума http://social.technet.microsoft.com
The table below shows which Windows operating systems can be upgraded to which editions of this release of Windows Server 2008 R2.
Note the following general guidelines for supported paths:
- In-place upgrades from 32-bit to 64-bit architectures are not supported. All editions of Windows Server 2008 R2 are 64-bit only.
- In-place upgrades from one language to another are not supported.
- In-place upgrades from one build type (fre to chk, for example) are not supported.
- If you do not see your current version in the left column, upgrade to this release of Windows Server 2008 R2 is not supported.
| If you are running: | You can upgrade to this edition: |
| Windows Server 2003 Standard Edition with Service Pack 2 (SP2) or Windows Server 2003 R2 Standard Edition | Windows Server 2008 R2 Standard, Windows Server 2008 R2 Enterprise |
| Windows Server 2003 Enterprise Edition with SP2 or Windows Server 2003 R2 Enterprise Edition | Windows Server 2008 R2 Enterprise, Windows Server 2008 R2 Datacenter |
| Windows Server 2003 Datacenter Edition with SP2 or Windows Server 2003 R2 Datacenter Edition | Windows Server 2008 R2 Datacenter |
| Server Core installation of Windows Server 2008 Standard with or without SP2 | Server Core installation of either Windows Server 2008 R2 Standard or Windows Server 2008 R2 Enterprise |
| Server Core installation of Windows Server 2008 Enterprise with or without SP2 | Server Core installation of either Windows Server 2008 R2 Enterprise or Windows Server 2008 R2 Datacenter |
| Server Core installation of Windows Server 2008 Datacenter | Server Core installation of Windows Server 2008 R2 Datacenter |
| Server Core installation of Windows Web Server 2008 with or without SP2 | Server Core installation of either Windows Server 2008 R2 Standard or Windows Web Server 2008 R2 |
| Full installation of Windows Server 2008 Standard with or without SP2 | Full installation of either Windows Server 2008 R2 Standard or Windows Server 2008 R2 Enterprise |
| Full installation of Windows Server 2008 Enterprise with or without SP2 | Full installation of either Windows Server 2008 R2 Enterprise or Windows Server 2008 R2 Datacenter |
| Full installation of Windows Server 2008 Datacenter with or without SP2 | Full installation of either Windows Server 2008 R2 Datacenter |
| Full installation of Windows Web Server 2008 with or without SP2 | Full installation of either Windows Server 2008 R2 Standard or Windows Web Server 2008 R2 |
| Server Core installation of Windows Server 2008 R2 Standard | Server Core installation of either Windows Server 2008 R2 Standard (repair in place) or Windows Server 2008 R2 Enterprise |
| Server Core installation of Windows Server 2008 R2 Enterprise | Server Core installation of either Windows Server 2008 R2 Enterprise (repair in place) or Windows Server 2008 R2 Datacenter |
| Server Core installation of Windows Server 2008 R2 Datacenter | Server Core installation of either Windows Server 2008 R2 Datacenter (repair in place) |
| Server Core installation of Windows Web Server 2008 R2 | Server Core installation of either Windows Web Server 2008 R2 (repair in place) or Windows Server 2008 R2 Standard |
| Full installation of Windows Server 2008 R2 Standard | Full installation of either Windows Server 2008 R2 Standard (repair in place) or Windows Server 2008 R2 Enterprise |
| Full installation of Windows Server 2008 R2 Enterprise | Full installation of either Windows Server 2008 R2 Enterprise (repair in place) or Windows Server 2008 R2 Datacenter |
| Full installation of Windows Server 2008 R2 Datacenter | Full installation of either Windows Server 2008 R2 Datacenter (repair in place) |
| Full installation of Windows Web Server 2008 R2 | Full installation of either Windows Web Server 2008 R2 (repair in place) or Windows Server 2008 R2 Standard |
пятница, 4 сентября 2009 г.
Модель OSI
OSI 7 layers model – создана организацией ISO в 1984 году (обратите внимание на инверсию слов ISO - OSI).
Формальное определение OSI: многоуровневое абстрактное представление и объяснение коммуникаций и дизайна протоколов компьютерных сетей.
Уровень (Layer) – это набор функций, которые обеспечивают сервисы вышележащему уровню и получают услуги от нижележащего уровня.
Сетевой протокол (Network protocol) — набор правил, позволяющий осуществлять соединение и обмен данными между двумя и более включёнными в сеть устройствами.
Для чего нужна модель OSI?
OSI – прекрасный способ изучения сетевой архитектуры. В любой области для решения сложной задачи ее раскладывают на составные элементы, которые поддаются решению. Сети и набор протоколов связи довольно сложны и разложение на уровни очень облегчает задачу объяснения и понимания проблемы.
Уровни также дают возможность создавать совместимые по интерфейсам (стандартным способам взаимодействия) и, в то же время, независимые протоколы, т.к. скрывают (наподобие черного ящика) технологии каждого уровня.
Как результат, производители протоколов и оборудования (сетевых карт, роутеров, свитчей и т.д.) получают возможность вместо одного протокола внедрить другой, более эффективный, не меняя при этом протоколы других уровней.
Например, на втором уровне вместо Ethernet можно использовать Token Ring или Frame Relay, а программы или вышележащие протоколы не будут об этом догадываться и продолжат работать как обычно.
Или, на физическом уровне, вместо медного кабеля можно использовать оптику или Wireless, а другие протоколы и программы не будут иметь об этом понятия.
В результате получается такой конструктор из слоев, где каждый слой-уровень можно заменять другими "деталями" без вреда для всей конструкции.
Пример из жизни: если у "Мерседеса" меняют коробку передач, не обязательно менять мотор или корпус, достаточно чтобы интерфейс между коробкой и другими "слоями" оставался тем же.
И, кстати, об интерфейсах: руль и педали – это пример интерфейса (стандартного способа взаимодействия) между человеком и машиной.
Вообщем, как всегда выигрывает стандартизация и взаимозаменяемость.
Ну, а поскольку сети рождены для соединения различного оборудования, средств передачи (media), протоколов, то стандартизация здесь важнее, чем во многих других областях.
А теперь настало время познакомиться непосредственно с самой моделью OSI. Кстати, она родилась в качестве теоретической и только потом были осуществлены попытки (не слишком удачные) внедрения ее в практику.
OSI 7 Layers Model
L7. APPLICATION
L6. PRESENTATION
L5. SESSION
L4. TRANSPORT
L3. NETWORK
L2. DATA LINK
L1. PHYSICAL
>>>=====
На рисунке схематически изображены уровни модели OSI, которых насчитывается 7.
Стандартный случай взаимодействия двух сетевых сущностей (компьютеров, роутеров и т.д.) таков: два хоста (компьютера, роутера и т.д.) заинтересованы создать логические коммуникации по горизонтали, т.е. между собой, с целью предачи информации.
С другой стороны, реальное взаимодействие происходит по вертикали, когда информация передается от какой-либо аппликации вниз по всем уровням (вертикально) и лишь затем транспортируется на другой хост (горизонтальное взаимодействие на уровне ниже первого).
Итак, по горизонтали мы имеем логические, виртуальные коммуникации при помощи протоколов, по вертикали – реальные, через связующие интерфейсы (для программистов замечу - API интерфейсы).
Теперь сравним дата-коммуникации с работой почты.
Представим себе писателя, который пишет роман и хочет передать его редактору для отзыва и правки.
Layer7. APPLICATION - Писатель отдает роман секретарше
Layer6. PRESENTATION
Layer5. SESSION
Layer4. TRANSPORT - Секретарша делит роман на листы-сегменты
Layer3. NETWORK - Секретарша надписывает адрес
Layer2. DATA LINK - Секретарша бросает конверт в почтовый ящик
Layer1. PHYSICAL - Почта из почтового ящика передается почтальону
Layer0. Почтальон доставляет почту ====>>
Далее следует объяснение представленного рисунка.
Layers 7-6-5. Писатель (все три верхних уровня аппликаций) передает роман секретарше.
Layer 4. Секретарша (транспортный уровень) разделяет его на отдельные листы, вкладывает их в конверты, нумерует и надписывает имя адресата (при помощи протокола TCP поток данных разделяется на сегменты, каждый из которых получает последовательный номер, а также номер порта).
Layer 3. Следующая секретарша (сетевой уровень) надписывает адрес (протокол IP добавляет IP адрес в заголовок пакета).
Layer 2. Еще одна секретарша (уровень Data-Link) берет конверт и бросает его в почтовый ящик (передает фрейм сетевой карте). Кроме того в заголовок фрейма добавляется MAC-адрес ближайшего роутера (обычно в свойствах TCP/IP он называется Default Gateway), хотя реальный почтальон и сам знает, где находится ближайшее почтовое отделение.
На этом уровне взаимодействуют драйвер и сетевая карта.
Layer 1. Почта из почтового ящика (сетевой карты на физическом уровне) передается почтальону (средству передачи, например медному кабелю), который на велосипеде доставляет ее в почтовое отделение (сетевые импульсы от сетевой карты по кабелям локальной сети или другими средствами приходят на Default Gateway), которое распределяет все приходящие конверты-пакеты по месту назначения (роутинг) и перегружает их на соответствующий транспорт, движущийся в нужном направлении: машину, корабль, самолет, (медный или оптический кабель локальной сети, сериальный интерфейс глобальной сети, инфракрасное или микроволновое излучение, радио-излучение со спутников и т.д.).
В итоге роман прибывает в место назначения (другой хост) разными способами и путями.
Затем наш роман претерпевает обратный процесс подъема по коммуникативным уровням на другом хосте и, в итоге, попадает на стол редактору (или в нужную аппликацию). Обратите внимание, что писателя и редактора (уровень аппликаций) интересует только взаимодействие между собой (горизонтальное), хотя по техническим причинам им приходится пользоваться услугами помощников - нижележащих уровней (т.е. вертикальными взаимодействиями).
Кстати, сами компьютерные аппликации (Word, Internet Explorer и т.д.) находятся выше уровня аппликаций (L7), а передача по проводам или другим средствам коммуникаций, ниже физического уровня (L1).
Некоторые считают, правда, что средства коммуникаций находятся непосредственно на первом уровне, но мы будем придерживаться мнения таких авторитетов, как Эндрю Таненбаум, создатель системы MINIX (свободная Unix-подобная операционная система для студенческих лабораторий) и знаменитой книги по компьютерным сетям, которая стала фактическим стандартом в данной области.
В дальнейшем мы рассмотрим, что происходит на пути следования, но уже сейчас можно заметить, что информация периодически поднимается до 3-го уровня, и лишь в конце, на целевом хосте, она восходит на самый верх к своей цели. Обычно таковой является какая-либо программа.
Также, в дальнейшем, мы подробно разберем, что же происходит между 2-мя хостами, когда кто-либо пишет в адресной строке своего Internet Explorer:
http://www.google.com
Правильный и полный ответ на этот вопрос является признаком хорошего осознавания сетевых процессов и определенного профессионализма.
Но, вернемся к нашим баранам :).
Модель OSI не является единственной моделью сетевых взаимодействий.
Из других, самая известная – модель TCP/IP.
Она отличается тем, что была создана на практике до создания теоретических обоснований. Как результат, она гораздо эффективнее в реальной практике, чем модель OSI и является сегодня стандартом De Facto.
Нужно сразу отметить, что TCP/IP - это и модель и набор действующих протоколов. Причем количество протоколов не два, как можно было бы предположить по названию, а гораздо больше.
В TCP/IP некоторые протоколы занимают сразу несколько уровней в нарушение строгих правил OSI, где каждому протоколу соответствует свой определенный уровень, который выполняет только ему отведенные функции.
В модели TCP/IP существует всего 4 уровня: группы 3-х верхних аппликативных и 2-х нижних модели OSI слиты каждая в единственный уровень модели TCP/IP, что уменьшает количество уровней и ускоряет процессы вертикальных коммуникации. Излишняя подробность OSI уменьшает реальную производительность, т.к. каждое взаимодействие между уровнями занимает время. Кроме того в OSI функции коррекции ошибок дублируются на 2 и 4 уровнях, что также отнимает время.
В то же время разбивка по слоям нужна и, даже, необходима. Можно, конечно, вообразить некий единый протокол, который будет простираться на все 7 уровней OSI. За счет отсутствия вертикальных взаимодействий между разными протоколами он будет, конечно, очень быстрым и никогда не возникнет проблем совместимости протоколов. Но это будет, так сказать, "одноразовый" протокол, т.е. им сможет воспользоваться лишь одна какая-то специфическая программа. В принципе, каждая программа, нуждающаяся в сетевых взаимодействиях, могла бы иметь свой собственный специализированный протокол. Как и каждый специализированный аппарат или программа, такой протокол мог бы быть чрезвычайно эффективным также и потому, что был бы совершенно лишен лишних универсальных функций, ведь универсальность добавляется, так сказать, "на всякий случай". Это напоминает эффективность DOS-овских игр, каждая из которых имела прямой доступ к железу компьютера и собственные драйверы (аналог протоколов). Эти игры работали очень быстро даже на слабом железе. Но мир почему-то все же отказался от такой эффективности в пользу универсальности. Уж очень она удобна и невероятно добавляет гибкости, а эффективность достигается другими способами, да и не во всех случаях эффективность стоит во главе угла, хотя и всегда принимается во внимание.
Существует также удобная 5-уровневая модель, которая является компромиссом между OSI и TCP/IP.
По аналогии с TCP/IP 3 верхних уровня слиты в один - аппликативный, но 2 нижних (Phisycal и DataLink) разделены так же как и в модели OSI.
(продолжение следует)
Формальное определение OSI: многоуровневое абстрактное представление и объяснение коммуникаций и дизайна протоколов компьютерных сетей.
Уровень (Layer) – это набор функций, которые обеспечивают сервисы вышележащему уровню и получают услуги от нижележащего уровня.
Сетевой протокол (Network protocol) — набор правил, позволяющий осуществлять соединение и обмен данными между двумя и более включёнными в сеть устройствами.
Для чего нужна модель OSI?
OSI – прекрасный способ изучения сетевой архитектуры. В любой области для решения сложной задачи ее раскладывают на составные элементы, которые поддаются решению. Сети и набор протоколов связи довольно сложны и разложение на уровни очень облегчает задачу объяснения и понимания проблемы.
Уровни также дают возможность создавать совместимые по интерфейсам (стандартным способам взаимодействия) и, в то же время, независимые протоколы, т.к. скрывают (наподобие черного ящика) технологии каждого уровня.
Как результат, производители протоколов и оборудования (сетевых карт, роутеров, свитчей и т.д.) получают возможность вместо одного протокола внедрить другой, более эффективный, не меняя при этом протоколы других уровней.
Например, на втором уровне вместо Ethernet можно использовать Token Ring или Frame Relay, а программы или вышележащие протоколы не будут об этом догадываться и продолжат работать как обычно.
Или, на физическом уровне, вместо медного кабеля можно использовать оптику или Wireless, а другие протоколы и программы не будут иметь об этом понятия.
В результате получается такой конструктор из слоев, где каждый слой-уровень можно заменять другими "деталями" без вреда для всей конструкции.
Пример из жизни: если у "Мерседеса" меняют коробку передач, не обязательно менять мотор или корпус, достаточно чтобы интерфейс между коробкой и другими "слоями" оставался тем же.
И, кстати, об интерфейсах: руль и педали – это пример интерфейса (стандартного способа взаимодействия) между человеком и машиной.
Вообщем, как всегда выигрывает стандартизация и взаимозаменяемость.
Ну, а поскольку сети рождены для соединения различного оборудования, средств передачи (media), протоколов, то стандартизация здесь важнее, чем во многих других областях.
А теперь настало время познакомиться непосредственно с самой моделью OSI. Кстати, она родилась в качестве теоретической и только потом были осуществлены попытки (не слишком удачные) внедрения ее в практику.
OSI 7 Layers Model
L7. APPLICATION
L6. PRESENTATION
L5. SESSION
L4. TRANSPORT
L3. NETWORK
L2. DATA LINK
L1. PHYSICAL
>>>=====
На рисунке схематически изображены уровни модели OSI, которых насчитывается 7.
Стандартный случай взаимодействия двух сетевых сущностей (компьютеров, роутеров и т.д.) таков: два хоста (компьютера, роутера и т.д.) заинтересованы создать логические коммуникации по горизонтали, т.е. между собой, с целью предачи информации.
С другой стороны, реальное взаимодействие происходит по вертикали, когда информация передается от какой-либо аппликации вниз по всем уровням (вертикально) и лишь затем транспортируется на другой хост (горизонтальное взаимодействие на уровне ниже первого).
Итак, по горизонтали мы имеем логические, виртуальные коммуникации при помощи протоколов, по вертикали – реальные, через связующие интерфейсы (для программистов замечу - API интерфейсы).
Теперь сравним дата-коммуникации с работой почты.
Представим себе писателя, который пишет роман и хочет передать его редактору для отзыва и правки.
Layer7. APPLICATION - Писатель отдает роман секретарше
Layer6. PRESENTATION
Layer5. SESSION
Layer4. TRANSPORT - Секретарша делит роман на листы-сегменты
Layer3. NETWORK - Секретарша надписывает адрес
Layer2. DATA LINK - Секретарша бросает конверт в почтовый ящик
Layer1. PHYSICAL - Почта из почтового ящика передается почтальону
Layer0. Почтальон доставляет почту ====>>
Далее следует объяснение представленного рисунка.
Layers 7-6-5. Писатель (все три верхних уровня аппликаций) передает роман секретарше.
Layer 4. Секретарша (транспортный уровень) разделяет его на отдельные листы, вкладывает их в конверты, нумерует и надписывает имя адресата (при помощи протокола TCP поток данных разделяется на сегменты, каждый из которых получает последовательный номер, а также номер порта).
Layer 3. Следующая секретарша (сетевой уровень) надписывает адрес (протокол IP добавляет IP адрес в заголовок пакета).
Layer 2. Еще одна секретарша (уровень Data-Link) берет конверт и бросает его в почтовый ящик (передает фрейм сетевой карте). Кроме того в заголовок фрейма добавляется MAC-адрес ближайшего роутера (обычно в свойствах TCP/IP он называется Default Gateway), хотя реальный почтальон и сам знает, где находится ближайшее почтовое отделение.
На этом уровне взаимодействуют драйвер и сетевая карта.
Layer 1. Почта из почтового ящика (сетевой карты на физическом уровне) передается почтальону (средству передачи, например медному кабелю), который на велосипеде доставляет ее в почтовое отделение (сетевые импульсы от сетевой карты по кабелям локальной сети или другими средствами приходят на Default Gateway), которое распределяет все приходящие конверты-пакеты по месту назначения (роутинг) и перегружает их на соответствующий транспорт, движущийся в нужном направлении: машину, корабль, самолет, (медный или оптический кабель локальной сети, сериальный интерфейс глобальной сети, инфракрасное или микроволновое излучение, радио-излучение со спутников и т.д.).
В итоге роман прибывает в место назначения (другой хост) разными способами и путями.
Затем наш роман претерпевает обратный процесс подъема по коммуникативным уровням на другом хосте и, в итоге, попадает на стол редактору (или в нужную аппликацию). Обратите внимание, что писателя и редактора (уровень аппликаций) интересует только взаимодействие между собой (горизонтальное), хотя по техническим причинам им приходится пользоваться услугами помощников - нижележащих уровней (т.е. вертикальными взаимодействиями).
Кстати, сами компьютерные аппликации (Word, Internet Explorer и т.д.) находятся выше уровня аппликаций (L7), а передача по проводам или другим средствам коммуникаций, ниже физического уровня (L1).
Некоторые считают, правда, что средства коммуникаций находятся непосредственно на первом уровне, но мы будем придерживаться мнения таких авторитетов, как Эндрю Таненбаум, создатель системы MINIX (свободная Unix-подобная операционная система для студенческих лабораторий) и знаменитой книги по компьютерным сетям, которая стала фактическим стандартом в данной области.
В дальнейшем мы рассмотрим, что происходит на пути следования, но уже сейчас можно заметить, что информация периодически поднимается до 3-го уровня, и лишь в конце, на целевом хосте, она восходит на самый верх к своей цели. Обычно таковой является какая-либо программа.
Также, в дальнейшем, мы подробно разберем, что же происходит между 2-мя хостами, когда кто-либо пишет в адресной строке своего Internet Explorer:
http://www.google.com
Правильный и полный ответ на этот вопрос является признаком хорошего осознавания сетевых процессов и определенного профессионализма.
Но, вернемся к нашим баранам :).
Модель OSI не является единственной моделью сетевых взаимодействий.
Из других, самая известная – модель TCP/IP.
Она отличается тем, что была создана на практике до создания теоретических обоснований. Как результат, она гораздо эффективнее в реальной практике, чем модель OSI и является сегодня стандартом De Facto.
Нужно сразу отметить, что TCP/IP - это и модель и набор действующих протоколов. Причем количество протоколов не два, как можно было бы предположить по названию, а гораздо больше.
В TCP/IP некоторые протоколы занимают сразу несколько уровней в нарушение строгих правил OSI, где каждому протоколу соответствует свой определенный уровень, который выполняет только ему отведенные функции.
В модели TCP/IP существует всего 4 уровня: группы 3-х верхних аппликативных и 2-х нижних модели OSI слиты каждая в единственный уровень модели TCP/IP, что уменьшает количество уровней и ускоряет процессы вертикальных коммуникации. Излишняя подробность OSI уменьшает реальную производительность, т.к. каждое взаимодействие между уровнями занимает время. Кроме того в OSI функции коррекции ошибок дублируются на 2 и 4 уровнях, что также отнимает время.
В то же время разбивка по слоям нужна и, даже, необходима. Можно, конечно, вообразить некий единый протокол, который будет простираться на все 7 уровней OSI. За счет отсутствия вертикальных взаимодействий между разными протоколами он будет, конечно, очень быстрым и никогда не возникнет проблем совместимости протоколов. Но это будет, так сказать, "одноразовый" протокол, т.е. им сможет воспользоваться лишь одна какая-то специфическая программа. В принципе, каждая программа, нуждающаяся в сетевых взаимодействиях, могла бы иметь свой собственный специализированный протокол. Как и каждый специализированный аппарат или программа, такой протокол мог бы быть чрезвычайно эффективным также и потому, что был бы совершенно лишен лишних универсальных функций, ведь универсальность добавляется, так сказать, "на всякий случай". Это напоминает эффективность DOS-овских игр, каждая из которых имела прямой доступ к железу компьютера и собственные драйверы (аналог протоколов). Эти игры работали очень быстро даже на слабом железе. Но мир почему-то все же отказался от такой эффективности в пользу универсальности. Уж очень она удобна и невероятно добавляет гибкости, а эффективность достигается другими способами, да и не во всех случаях эффективность стоит во главе угла, хотя и всегда принимается во внимание.
Существует также удобная 5-уровневая модель, которая является компромиссом между OSI и TCP/IP.
По аналогии с TCP/IP 3 верхних уровня слиты в один - аппликативный, но 2 нижних (Phisycal и DataLink) разделены так же как и в модели OSI.
(продолжение следует)
Подписаться на:
Сообщения (Atom)