Git Модели бранчевания - Проблематика
Сегодня хотелось бы порассуждать о важности выбора модели бранчевания в git репозиториях.
Наверно, самый просто и быстрый ответ, который может быть принят - это как удобно разработке - уменьшение конфликтов в коде и ускорение разработки. С этой позиции модель может стать исторически удобной для команды в данном репозитории.
Пока можно отметить только один минус, если модель бранчевания получилась очень творческой, то требуется дополнительное время на этапе онбординга нового члена команды, чтоб рассказать как это работает.
Вопрос становиться более глубоким если репозиториев становиться больше чем 1. В данном случае модель может выбранная на этапе выбора одного репозитория может быть масштабирована до нескольких репозиториев без какого-либо ущерба.
Из плюсов у нас появляется какая-то стандартизация, дополнительных минусов пока не появляется.
Следующий этап погружения, если проектов (совокупности репозиториев решающие бизнез задачи) становится больше, если в каждом проект появляется своя модель бранчевания, появляются ряд недостатков:
1. Усложняется переключение/переход между проектами
2. Усложняется CI/CD процесс (девопсу требуется поддерживать несколько кастомных процессов)
В данный момент минусов становиться больше, чем плюсов. И как раз тут следует задуматься от стандартизации и унификации процессов разработки и CI/CD.
Проблема для индустрии не новая и существует много решений, которые стандартизирую данный процесс. Стоит посмотреть в сторону различный решений:
3. GitFlow
4. GitHub Flow
5. GitLab Flow
6. Trunk-based development
#git #branching_model #branching_strategies
Сегодня хотелось бы порассуждать о важности выбора модели бранчевания в git репозиториях.
Наверно, самый просто и быстрый ответ, который может быть принят - это как удобно разработке - уменьшение конфликтов в коде и ускорение разработки. С этой позиции модель может стать исторически удобной для команды в данном репозитории.
Пока можно отметить только один минус, если модель бранчевания получилась очень творческой, то требуется дополнительное время на этапе онбординга нового члена команды, чтоб рассказать как это работает.
Вопрос становиться более глубоким если репозиториев становиться больше чем 1. В данном случае модель может выбранная на этапе выбора одного репозитория может быть масштабирована до нескольких репозиториев без какого-либо ущерба.
Из плюсов у нас появляется какая-то стандартизация, дополнительных минусов пока не появляется.
Следующий этап погружения, если проектов (совокупности репозиториев решающие бизнез задачи) становится больше, если в каждом проект появляется своя модель бранчевания, появляются ряд недостатков:
1. Усложняется переключение/переход между проектами
2. Усложняется CI/CD процесс (девопсу требуется поддерживать несколько кастомных процессов)
В данный момент минусов становиться больше, чем плюсов. И как раз тут следует задуматься от стандартизации и унификации процессов разработки и CI/CD.
Проблема для индустрии не новая и существует много решений, которые стандартизирую данный процесс. Стоит посмотреть в сторону различный решений:
3. GitFlow
4. GitHub Flow
5. GitLab Flow
6. Trunk-based development
#git #branching_model #branching_strategies
⚡1❤1🔥1
Модель Gitflow - это стратегия управления ветками в системе контроля версий Git, которая предназначена для организации рабочего процесса в разработке программного обеспечения. Эта модель была разработана Винсентом Дриессеном и описана в его статье "A successful Git branching model". Gitflow обеспечивает структурированный и надежный способ управления разработкой и релизами.
Основные концепции модели Gitflow включают следующее:
Main Branches:
• Master: Основная ветка, в которой содержится стабильный и готовый к развертыванию код. Каждый коммит в этой ветке представляет собой новую версию продукта.
• Develop: Ветка разработки, в которой находятся последние изменения, включая новые функции и исправления багов. Изменения из этой ветки могут периодически сливаться в мастер после тестирования и ревью.
Supporting Branches:
• Feature Branches: Каждая новая функция или задача разрабатывается в собственной ветке. Feature branches создаются от ветки Develop и сливаются обратно в нее после завершения работы.
• Release Branches: Ветки для подготовки к выпуску новых версий продукта. Они создаются от ветки Develop и используются для фиксации последних изменений и подготовки к релизу. После завершения тестирования и устранения ошибок они сливаются как в мастер (для релизов) и в Develop (для продолжения разработки).
• Hotfix Branches: Ветки, создаваемые для немедленного исправления критических ошибок в текущей версии продукта. Они создаются от мастера и после исправления ошибок сливаются как в мастер, так и в Develop.
Workflow:
• Новые функции начинаются в Feature branches и сливаются обратно в Develop.
• Для подготовки к выпуску создаются Release branches, в которые сливаются последние изменения. Затем они сливаются как в мастер (для релизов), так и в Develop (для продолжения разработки).
• Hotfix branches используются для немедленных исправлений, которые сливаются в мастер и Develop.
Модель Gitflow обеспечивает хороший контроль над релизами и управление разработкой, что особенно полезно в больших проектах с несколькими разработчиками. Она помогает разделять разработку новых функций и релизы, обеспечивая стабильность мастера и развитие новых возможностей в Develop.
#git #branching_model #branching_strategies
Основные концепции модели Gitflow включают следующее:
Main Branches:
• Master: Основная ветка, в которой содержится стабильный и готовый к развертыванию код. Каждый коммит в этой ветке представляет собой новую версию продукта.
• Develop: Ветка разработки, в которой находятся последние изменения, включая новые функции и исправления багов. Изменения из этой ветки могут периодически сливаться в мастер после тестирования и ревью.
Supporting Branches:
• Feature Branches: Каждая новая функция или задача разрабатывается в собственной ветке. Feature branches создаются от ветки Develop и сливаются обратно в нее после завершения работы.
• Release Branches: Ветки для подготовки к выпуску новых версий продукта. Они создаются от ветки Develop и используются для фиксации последних изменений и подготовки к релизу. После завершения тестирования и устранения ошибок они сливаются как в мастер (для релизов) и в Develop (для продолжения разработки).
• Hotfix Branches: Ветки, создаваемые для немедленного исправления критических ошибок в текущей версии продукта. Они создаются от мастера и после исправления ошибок сливаются как в мастер, так и в Develop.
Workflow:
• Новые функции начинаются в Feature branches и сливаются обратно в Develop.
• Для подготовки к выпуску создаются Release branches, в которые сливаются последние изменения. Затем они сливаются как в мастер (для релизов), так и в Develop (для продолжения разработки).
• Hotfix branches используются для немедленных исправлений, которые сливаются в мастер и Develop.
Модель Gitflow обеспечивает хороший контроль над релизами и управление разработкой, что особенно полезно в больших проектах с несколькими разработчиками. Она помогает разделять разработку новых функций и релизы, обеспечивая стабильность мастера и развитие новых возможностей в Develop.
#git #branching_model #branching_strategies
GitHub Flow - это простая и эффективная стратегия управления ветками и разработкой программного обеспечения, которая активно используется на GitHub и других платформах для совместной разработки. Она ориентирована на непрерывное развертывание (Continuous Deployment) и поддерживает быстрое и стабильное развитие приложений. Вот основные принципы GitHub Flow:
Main Branch:
• Вся разработка происходит в основной ветке, которая часто называется main, master или другим аналогичным именем.
• Эта ветка содержит всегда готовую к развертыванию версию продукта.
Feature Branches:
• Каждая новая функция или задача начинается с создания отдельной ветки (feature branch) от основной ветки.
• Название ветки часто описывает, над чем именно работает разработчик.
Commit and Push:
• Разработчики вносят изменения в свою ветку, фиксируют их с помощью коммитов и отправляют изменения на удаленный сервер с использованием команды git push.
Pull Request (PR):
• После завершения работы над функцией, разработчик создает Pull Request для объединения (merge) своей ветки с основной веткой.
• PR содержит описание изменений, комментарии и может быть просмотрен другими членами команды.
Code Review:
• Проверка кода (code review) является важной частью GitHub Flow.
• Другие разработчики или члены команды просматривают изменения в Pull Request, предоставляют комментарии и рецензии, обсуждают и утверждают изменения.
Merging:
• После успешного код-ревью и устранения всех комментариев, Pull Request может быть объединен в основную ветку.
• Это происходит с помощью кнопки "Merge" на GitHub.
Deployment:
• После объединения изменений в основную ветку, новая версия приложения автоматически разворачивается на тестовом или продукционном сервере.
Continuous Integration (CI):
• GitHub Flow активно использует системы непрерывной интеграции (CI), чтобы автоматически проверять и тестировать код на каждом этапе разработки.
Rollback:
• Если после развертывания обнаруживаются проблемы, можно легко вернуться к предыдущей стабильной версии, так как основная ветка всегда содержит готовую к развертыванию версию.
GitHub Flow способствует быстрой и надежной разработке программного обеспечения, с акцентом на непрерывном развертывании и высокой степени автоматизации тестирования и развертывания.
#git #branching_model #branching_strategies
Main Branch:
• Вся разработка происходит в основной ветке, которая часто называется main, master или другим аналогичным именем.
• Эта ветка содержит всегда готовую к развертыванию версию продукта.
Feature Branches:
• Каждая новая функция или задача начинается с создания отдельной ветки (feature branch) от основной ветки.
• Название ветки часто описывает, над чем именно работает разработчик.
Commit and Push:
• Разработчики вносят изменения в свою ветку, фиксируют их с помощью коммитов и отправляют изменения на удаленный сервер с использованием команды git push.
Pull Request (PR):
• После завершения работы над функцией, разработчик создает Pull Request для объединения (merge) своей ветки с основной веткой.
• PR содержит описание изменений, комментарии и может быть просмотрен другими членами команды.
Code Review:
• Проверка кода (code review) является важной частью GitHub Flow.
• Другие разработчики или члены команды просматривают изменения в Pull Request, предоставляют комментарии и рецензии, обсуждают и утверждают изменения.
Merging:
• После успешного код-ревью и устранения всех комментариев, Pull Request может быть объединен в основную ветку.
• Это происходит с помощью кнопки "Merge" на GitHub.
Deployment:
• После объединения изменений в основную ветку, новая версия приложения автоматически разворачивается на тестовом или продукционном сервере.
Continuous Integration (CI):
• GitHub Flow активно использует системы непрерывной интеграции (CI), чтобы автоматически проверять и тестировать код на каждом этапе разработки.
Rollback:
• Если после развертывания обнаруживаются проблемы, можно легко вернуться к предыдущей стабильной версии, так как основная ветка всегда содержит готовую к развертыванию версию.
GitHub Flow способствует быстрой и надежной разработке программного обеспечения, с акцентом на непрерывном развертывании и высокой степени автоматизации тестирования и развертывания.
#git #branching_model #branching_strategies
Trunk Based Development (TBD) - это методология управления версиями и разработки программного обеспечения, которая сосредотачивается на минимизации использования ветвления (branching) и максимизации интеграции изменений в основную (trunk) ветку как можно раньше. Эта методология стремится ускорить процесс разработки и улучшить стабильность кодовой базы.
Основные принципы Trunk Based Development включают следующее:
Основная (Trunk) ветка:
• В центре TBD находится основная ветка, называемая также "транк" или "главная ветка" (trunk).
• Вся разработка происходит внутри этой ветки.
Минимальное использование ветвления:
• TBD призывает минимизировать создание долгоживущих веток для функций или задач.
• Разработчики вместо этого вносят изменения непосредственно в основную ветку.
Feature Toggles (Feature Flags):
• Для добавления новых функций или экспериментальных изменений в код используются функциональные флаги (feature flags).
• Эти флаги позволяют включать и отключать функции на уровне конфигурации, даже если код уже находится в основной ветке.
Моментальные интеграции:
• Разработчики регулярно коммитят и сразу интегрируют свои изменения в основную ветку.
• Это способствует постоянной интеграции (Continuous Integration) и обнаружению конфликтов и ошибок на ранних этапах.
Тестирование и откат (Rollback):
• Тестирование кода и функциональных флагов играет важную роль в TBD.
• В случае обнаружения проблем, изменения могут быть быстро откачены (rolled back).
Мониторинг и обратная связь:
• TBD подразумевает активное мониторинг изменений в реальном времени.
• Системы мониторинга и инструменты обратной связи помогают быстро обнаруживать и реагировать на проблемы.
Trunk Based Development предоставляет множество преимуществ, таких как ускорение процесса разработки, сокращение времени до выпуска новой функциональности и обеспечение более стабильного и надежного кода. Однако эта методология может потребовать более активного тестирования и мониторинга, чтобы обнаруживать и устранять проблемы на ранних этапах разработки.
#git #branching_model #branching_strategies
Основные принципы Trunk Based Development включают следующее:
Основная (Trunk) ветка:
• В центре TBD находится основная ветка, называемая также "транк" или "главная ветка" (trunk).
• Вся разработка происходит внутри этой ветки.
Минимальное использование ветвления:
• TBD призывает минимизировать создание долгоживущих веток для функций или задач.
• Разработчики вместо этого вносят изменения непосредственно в основную ветку.
Feature Toggles (Feature Flags):
• Для добавления новых функций или экспериментальных изменений в код используются функциональные флаги (feature flags).
• Эти флаги позволяют включать и отключать функции на уровне конфигурации, даже если код уже находится в основной ветке.
Моментальные интеграции:
• Разработчики регулярно коммитят и сразу интегрируют свои изменения в основную ветку.
• Это способствует постоянной интеграции (Continuous Integration) и обнаружению конфликтов и ошибок на ранних этапах.
Тестирование и откат (Rollback):
• Тестирование кода и функциональных флагов играет важную роль в TBD.
• В случае обнаружения проблем, изменения могут быть быстро откачены (rolled back).
Мониторинг и обратная связь:
• TBD подразумевает активное мониторинг изменений в реальном времени.
• Системы мониторинга и инструменты обратной связи помогают быстро обнаруживать и реагировать на проблемы.
Trunk Based Development предоставляет множество преимуществ, таких как ускорение процесса разработки, сокращение времени до выпуска новой функциональности и обеспечение более стабильного и надежного кода. Однако эта методология может потребовать более активного тестирования и мониторинга, чтобы обнаруживать и устранять проблемы на ранних этапах разработки.
#git #branching_model #branching_strategies
Модель Release Branch Workflow - это методология управления версиями и разработки программного обеспечения, которая предполагает создание отдельных веток (release branches) для каждой версии продукта или релиза. Эта модель обычно используется в проектах, где требуется строгий контроль над процессом разработки и выпуска версий, а также в проектах, где необходимо поддерживать несколько стабильных версий продукта.
Вот основные шаги и принципы Release Branch Workflow:
Основные ветки:
• В репозитории существуют две основные ветки: main и develop.
• main - это ветка, которая содержит стабильный и готовый к развертыванию код.
• develop - это ветка разработки, в которой находятся последние изменения, включая новые функции и исправления багов.
Создание Release Branch:
• Перед тем как начать работу над новой версией продукта, создается отдельная ветка для подготовки к релизу (release branch).
• Ветка создается от ветки develop.
Тестирование и Подготовка:
• В ветке релиза происходит тестирование и устранение критических ошибок.
• Завершение работы над новой версией, включая обновление документации и версионирование, происходит в этой ветке.
Слияние в main и develop:
• После завершения тестирования и устранения ошибок, изменения из ветки релиза сливаются как в ветку main, так и в ветку develop.
• Слияние в main обозначает выпуск новой версии продукта.
Подготовка к следующему релизу:
• После завершения релиза ветка релиза обычно удаляется или заменяется на новую ветку для подготовки к следующему релизу.
Hotfixes (Критические исправления):
• Если после выпуска версии продукта обнаруживаются критические ошибки, создается отдельная ветка (hotfix branch) от ветки main, чтобы их исправить.
• После исправления ошибок изменения сливаются как в main, так и в develop.
Модель Release Branch Workflow обеспечивает структурированный и предсказуемый процесс разработки и выпуска версий продукта. Она позволяет командам тщательно тестировать каждую версию перед выпуском, а также обеспечивает возможность поддерживать стабильные версии продукта, даже если разрабатывается новая функциональность.
#git #branching_model #branching_strategies
Вот основные шаги и принципы Release Branch Workflow:
Основные ветки:
• В репозитории существуют две основные ветки: main и develop.
• main - это ветка, которая содержит стабильный и готовый к развертыванию код.
• develop - это ветка разработки, в которой находятся последние изменения, включая новые функции и исправления багов.
Создание Release Branch:
• Перед тем как начать работу над новой версией продукта, создается отдельная ветка для подготовки к релизу (release branch).
• Ветка создается от ветки develop.
Тестирование и Подготовка:
• В ветке релиза происходит тестирование и устранение критических ошибок.
• Завершение работы над новой версией, включая обновление документации и версионирование, происходит в этой ветке.
Слияние в main и develop:
• После завершения тестирования и устранения ошибок, изменения из ветки релиза сливаются как в ветку main, так и в ветку develop.
• Слияние в main обозначает выпуск новой версии продукта.
Подготовка к следующему релизу:
• После завершения релиза ветка релиза обычно удаляется или заменяется на новую ветку для подготовки к следующему релизу.
Hotfixes (Критические исправления):
• Если после выпуска версии продукта обнаруживаются критические ошибки, создается отдельная ветка (hotfix branch) от ветки main, чтобы их исправить.
• После исправления ошибок изменения сливаются как в main, так и в develop.
Модель Release Branch Workflow обеспечивает структурированный и предсказуемый процесс разработки и выпуска версий продукта. Она позволяет командам тщательно тестировать каждую версию перед выпуском, а также обеспечивает возможность поддерживать стабильные версии продукта, даже если разрабатывается новая функциональность.
#git #branching_model #branching_strategies
Модель Forking Workflow - это стратегия управления версиями и совместной разработки в системе контроля версий Git, которая основана на создании форков (forks) репозиториев. Эта модель часто используется в открытом исходном коде и в командах, где у разработчиков разные уровни доступа к репозиторию, или когда требуется более строгий контроль над процессом слияния изменений.
Вот основные принципы Forking Workflow:
Создание форка репозитория: Когда разработчик хочет внести изменения в репозиторий, он начинает с создания форка этого репозитория. Форк представляет собой копию репозитория, в которой разработчик будет вносить свои изменения.
Клонирование форка: Разработчик клонирует свой форк на локальную машину с помощью команды git clone. Это дает ему рабочую копию репозитория, с которой он будет работать.
Создание ветки: Разработчик создает новую ветку в своем форке для разработки конкретной функции или исправления бага. Вся работа проводится в этой ветке.
Коммиты и изменения: Разработчик вносит изменения в код в своей ветке и фиксирует их с помощью коммитов. Он может делать сколько угодно коммитов, чтобы разделить изменения на более мелкие части.
Push в форк: После завершения работы над функцией или исправлением бага, разработчик отправляет свои изменения в свой форк на сервер GitLab с помощью команды git push.
Создание Pull Request (PR): Разработчик создает Pull Request, чтобы запросить включение своих изменений из его форка в исходный репозиторий (обычно репозиторий организации или проекта).
Review и комментарии: Другие члены команды или сотрудники могут просматривать изменения в Pull Request, комментировать их, предлагать изменения и проводить код-ревью.
Мерж изменений: После успешного ревью и устранения всех комментариев администратор репозитория может принять Pull Request и включить изменения в исходный репозиторий.
Синхронизация с исходным репозиторием: Разработчик может периодически синхронизировать свой форк с исходным репозиторием, чтобы получить последние изменения из него. Это важно, чтобы избежать конфликтов при слиянии.
Модель Forking Workflow обеспечивает изоляцию изменений, что позволяет более независимо разрабатывать и согласовывать функциональность между разными участниками проекта. Это особенно полезно для проектов с большим числом вкладчиков и для открытых проектов с несколькими вкладчиками, которые не имеют прямого доступа к исходному репозиторию.
#git #branching_model #branching_strategies
Вот основные принципы Forking Workflow:
Создание форка репозитория: Когда разработчик хочет внести изменения в репозиторий, он начинает с создания форка этого репозитория. Форк представляет собой копию репозитория, в которой разработчик будет вносить свои изменения.
Клонирование форка: Разработчик клонирует свой форк на локальную машину с помощью команды git clone. Это дает ему рабочую копию репозитория, с которой он будет работать.
Создание ветки: Разработчик создает новую ветку в своем форке для разработки конкретной функции или исправления бага. Вся работа проводится в этой ветке.
Коммиты и изменения: Разработчик вносит изменения в код в своей ветке и фиксирует их с помощью коммитов. Он может делать сколько угодно коммитов, чтобы разделить изменения на более мелкие части.
Push в форк: После завершения работы над функцией или исправлением бага, разработчик отправляет свои изменения в свой форк на сервер GitLab с помощью команды git push.
Создание Pull Request (PR): Разработчик создает Pull Request, чтобы запросить включение своих изменений из его форка в исходный репозиторий (обычно репозиторий организации или проекта).
Review и комментарии: Другие члены команды или сотрудники могут просматривать изменения в Pull Request, комментировать их, предлагать изменения и проводить код-ревью.
Мерж изменений: После успешного ревью и устранения всех комментариев администратор репозитория может принять Pull Request и включить изменения в исходный репозиторий.
Синхронизация с исходным репозиторием: Разработчик может периодически синхронизировать свой форк с исходным репозиторием, чтобы получить последние изменения из него. Это важно, чтобы избежать конфликтов при слиянии.
Модель Forking Workflow обеспечивает изоляцию изменений, что позволяет более независимо разрабатывать и согласовывать функциональность между разными участниками проекта. Это особенно полезно для проектов с большим числом вкладчиков и для открытых проектов с несколькими вкладчиками, которые не имеют прямого доступа к исходному репозиторию.
#git #branching_model #branching_strategies
Социальная дилемма - хороший фильм показываюший как современные технологии и ИИ в частности, влияет на наше общество и какие проблемы из этого получаются - рекомендую к просмотру - https://www.kinopoisk.ru/film/1337788/
#кино
#кино
Кинопоиск
«Социальная дилемма» (The Social Dilemma, 2020)
🎬 Бывшие сотрудники Google, Facebook, Twitter, YouTube и многих других IT-гигантов рассказывают о своих разработках для компаний, почему они уволились, и о том, как разработанные ими алгоритмы пагубно влияют на жизнь людей и особенно — детей. Подробная информация…
🔥1
Протоколы TCP/IP создавались для организации передачи данных в ARPAnet, сети на базе коммутации пакетов.
Пакет - это блок данных, содержащий информацию, необходимую для доставки. В этом отношении пакет похож на письмо, адрес получателя отражен на конверте. Сеть с пакетной коммутацией использует адресную информацию пакетов для коммутации пакетов из одной физической сети в другую, перемещая их ближе к пункту назначения. Пакеты путешествуют по сети независимо друг от друга.
Формат пакета, определяемый протоколом Internet, называется дейтаграммой.
#сети
Пакет - это блок данных, содержащий информацию, необходимую для доставки. В этом отношении пакет похож на письмо, адрес получателя отражен на конверте. Сеть с пакетной коммутацией использует адресную информацию пакетов для коммутации пакетов из одной физической сети в другую, перемещая их ближе к пункту назначения. Пакеты путешествуют по сети независимо друг от друга.
Формат пакета, определяемый протоколом Internet, называется дейтаграммой.
#сети
UDP - это ненадежный протокол доставки дейтаграмм без организации логических соединений.
Если объем передаваемых данных невелик, издержки на создание соединений и отслеживание надежности доставки могут оказаться больше, чем затраты на повторную передачу всех данных. В таком случае UDP становится оптимальным протоколом транспортного уровня. Другими явными кандидатами на использование UDP являются приложения, работающие по принципу запрос-ответ. Ответ можно считать подтверждением приема запроса. Если ответ не поступил в течение определенного промежутка времени, приложение просто повторяет запрос. Кроме того, существуют приложения, в которых реализуются собственные методы обеспечения надежной доставки данных, так что они не ищут подобной функциональности в протоколах транспортного уровня. Для каждого из упомянутых типов приложений дополнительный уровень подтверждения приема станет причиной снижения производительности.
TCP - надежный, потоковый протокол, требующий создания логических соединений.
Надежность в TCP обеспечивает механизм подтверждения приема с повторной передачей (Positive Acknowledgment with Retransmission, PAR).
повторяет отправку данных до тех пор, пока не получит от системы-адресата подтверждение, что данные успешно получены. Единицей обмена данными для взаимодействующих модулей TCP является сегмент. Каждый сегмент содержит контрольную сумму, посредством которой получатель определяет целостность данных. Если сегмент данных получен в целости и сохранности, получатель отправляет источнику подтверждение. Повреждённые сегменты данных просто игнорируются получателем. По истечении установленного интервала ожидания модуль-источник TCP повторно выполняет передачу всех сегментов, для которых не были получены подтверждения.
#сети
Если объем передаваемых данных невелик, издержки на создание соединений и отслеживание надежности доставки могут оказаться больше, чем затраты на повторную передачу всех данных. В таком случае UDP становится оптимальным протоколом транспортного уровня. Другими явными кандидатами на использование UDP являются приложения, работающие по принципу запрос-ответ. Ответ можно считать подтверждением приема запроса. Если ответ не поступил в течение определенного промежутка времени, приложение просто повторяет запрос. Кроме того, существуют приложения, в которых реализуются собственные методы обеспечения надежной доставки данных, так что они не ищут подобной функциональности в протоколах транспортного уровня. Для каждого из упомянутых типов приложений дополнительный уровень подтверждения приема станет причиной снижения производительности.
TCP - надежный, потоковый протокол, требующий создания логических соединений.
Надежность в TCP обеспечивает механизм подтверждения приема с повторной передачей (Positive Acknowledgment with Retransmission, PAR).
повторяет отправку данных до тех пор, пока не получит от системы-адресата подтверждение, что данные успешно получены. Единицей обмена данными для взаимодействующих модулей TCP является сегмент. Каждый сегмент содержит контрольную сумму, посредством которой получатель определяет целостность данных. Если сегмент данных получен в целости и сохранности, получатель отправляет источнику подтверждение. Повреждённые сегменты данных просто игнорируются получателем. По истечении установленного интервала ожидания модуль-источник TCP повторно выполняет передачу всех сегментов, для которых не были получены подтверждения.
#сети
Сочетание IP-адреса и номера порта называется сокетом (socket).
Пара сокетов - сокет узла-получателя и сокет узла-источника определяет соединение для протоколов, ориентированных на работу с соединениями, таких как TCP.
#сети
Пара сокетов - сокет узла-получателя и сокет узла-источника определяет соединение для протоколов, ориентированных на работу с соединениями, таких как TCP.
#сети