아키텍처 간략 정리

1. MVC (Model-View-Controller)

구성 요소

• Model: 데이터와 비즈니스 로직을 관리합니다.
• View: 사용자에게 정보를 시각적으로 표시합니다.
• Controller: 사용자 요청을 처리하고 Model과 View를 연결합니다.

특징

• 역할이 분리되어 코드의 가독성과 재사용성이 높습니다.
• 사용자가 View와 상호작용하면 Controller가 이를 처리하고 Model을 업데이트한 후, View에 결과를 표시합니다.

활용

• 웹 애플리케이션(스프링 MVC, Ruby on Rails 등)
• 데스크톱 애플리케이션

2. MVVM (Model-View-ViewModel)

구성 요소

• Model: 데이터와 비즈니스 로직.
• View: UI 요소.
• ViewModel: View와 Model 사이의 중간 계층으로, View의 상태를 관리하고, 데이터 바인딩을 지원합니다.

특징

• 양방향 데이터 바인딩을 통해 View와 ViewModel의 동기화를 자동으로 처리합니다.
• View는 데이터에 대한 의존성을 최소화합니다.

활용

• WPF(Windows Presentation Foundation)
• Angular, Vue.js, React + Redux/MobX와 같은 SPA(Single Page Application) 프레임워크

3. MVP (Model-View-Presenter)

구성 요소

• Model: 데이터와 비즈니스 로직.
• View: 사용자 인터페이스(UI).
• Presenter: View의 로직을 담당하며 Model과 상호작용한 후 데이터를 View에 전달합니다.

특징

• View는 단순히 UI를 표시하는 역할만 하고, 모든 로직은 Presenter에서 처리됩니다.
• View와 Presenter는 1:1 관계를 갖습니다.

활용

• 안드로이드 애플리케이션
• 레거시 데스크톱 애플리케이션

4. Clean Architecture

구성 요소

• Entities: 애플리케이션의 비즈니스 규칙을 캡슐화.
• Use Cases: 애플리케이션의 특정 작업이나 기능을 정의.
• Interface Adapters: 데이터와 UI의 변환 계층.
• Frameworks & Drivers: 데이터베이스, UI, 외부 API 등.

특징

• 의존성 규칙: 안쪽 계층은 바깥쪽 계층을 알지 못합니다.
• 비즈니스 로직이 프레임워크와 독립적이어서 확장성과 유지보수가 용이합니다.

활용

• 대규모 시스템
• 멀티 플랫폼 애플리케이션

5. Layered Architecture (계층형 아키텍처)

구성 요소

• Presentation Layer: 사용자 인터페이스.
• Application Layer: 비즈니스 로직.
• Data Layer: 데이터베이스 및 데이터 액세스.

특징

• 계층 간 명확한 분리가 이루어집니다.
• 단순하고 이해하기 쉬운 구조지만, 복잡한 시스템에서 성능 저하가 있을 수 있습니다.

활용

• 전통적인 웹 애플리케이션(3-tier 아키텍처)
• 엔터프라이즈 애플리케이션

6. Microservices Architecture

구성 요소

• 애플리케이션을 독립적으로 배포 가능한 작은 서비스들로 나눕니다.
• 각 서비스는 고유한 비즈니스 기능을 담당하며 API로 통신합니다.

특징

• 독립적인 배포와 확장이 가능합니다.
• 서비스 간 통신 오버헤드가 있고, 분산 시스템의 복잡성이 증가할 수 있습니다.

활용

• 대규모 분산 시스템
• 클라우드 네이티브 애플리케이션

7. Event-Driven Architecture

구성 요소

• Event Producer: 이벤트를 생성하고 발행.
• Event Consumer: 이벤트를 처리.
• Event Broker: 이벤트를 전달하거나 중개.

특징

• 비동기 통신을 기반으로 설계되어 높은 확장성을 제공합니다.
• 복잡한 이벤트 흐름을 관리하기 위한 설계가 필요합니다.

활용

• IoT 시스템
• 실시간 애플리케이션(채팅, 트랜잭션 시스템)

8. Hexagonal Architecture (Ports and Adapters)

구성 요소

• Core (Application Logic): 애플리케이션의 핵심 비즈니스 로직.
• Ports: 외부와의 상호작용을 정의하는 인터페이스.
• Adapters: 특정 구현을 제공하여 Core와 통신.

특징

• 비즈니스 로직과 외부 시스템 간의 의존성을 최소화합니다.
• 높은 테스트 가능성과 확장성을 제공합니다.

활용

• 복잡한 도메인 로직이 있는 시스템
• 시스템 간 통합이 필요한 애플리케이션

9. Serverless Architecture

구성 요소

• 클라우드 기반 서비스와 함수(Function-as-a-Service)를 이용하여 애플리케이션을 실행.
• 서버를 관리하지 않고도 클라우드 제공자가 모든 인프라를 처리.

특징

• 확장성과 비용 효율성이 높습니다.
• 서버 환경에 대한 제어가 제한적입니다.

활용

• 이벤트 중심 애플리케이션
• 간단한 API 백엔드

10. CQRS (Command Query Responsibility Segregation)

구성 요소

• Command: 데이터 변경 작업(쓰기).
• Query: 데이터 읽기 작업.

특징

• 읽기와 쓰기를 분리하여 각 작업을 최적화합니다.
• 복잡한 시스템에서 동시성과 확장성을 지원합니다.

활용

• 이벤트 소싱 시스템
• 고성능 읽기/쓰기 작업이 필요한 시스템

11. Pipe and Filter Architecture

구성 요소

• Filters: 데이터를 처리하는 독립적인 컴포넌트.
• Pipes: 필터 간 데이터를 전달.

특징

• 데이터 흐름을 직관적으로 표현할 수 있습니다.
• 처리 단계가 많아지면 성능 저하가 발생할 수 있습니다.

활용

• 데이터 처리 파이프라인
• 이미지 또는 오디오 프로세싱

12. Service-Oriented Architecture (SOA)

구성 요소

• 독립적인 서비스들로 구성되며, 각 서비스는 특정 비즈니스 기능을 제공합니다.
• 서비스는 표준 프로토콜(예: SOAP, REST)을 통해 통신합니다.

특징

• 서비스 간 의존성이 낮아 확장성과 재사용성이 높습니다.
• 복잡한 통합과 관리가 필요합니다.

활용

• 엔터프라이즈 애플리케이션
• 분산 시스템

CSR에서 자바 스프링 백엔드 아키텍처

1. 계층형 아키텍처 사용 (Layered Architecture)
2. RESTful API 서버로 프론트엔드와 데이터 통신
3. JPA + Hibernate를 통한 데이터베이스 연동
4. JWT를 통한 보안 및 인증 처리
5. 마이크로서비스 및 API Gateway 적용 가능 (Spring Cloud Gateway)
6. 비즈니스 로직, 예외 처리, 로깅, 모니터링 구성

➡️ CSR 환경에서는 프론트엔드가 주로 UI를 렌더링하고, 자바 스프링 백엔드는 데이터 제공, 비즈니스 로직 처리, 보안, 데이터베이스 연동을 주로 담당합니다.

아키텍처 패턴 선택 가이드

1. 프로젝트 규모:
   • 작은 프로젝트: MVC, MVP
   • 대규모 프로젝트: Microservices, Clean Architecture
2. 프론트엔드 및 백엔드 협업:
   • 단일 애플리케이션: MVVM, MVC
   • 분리된 환경: RESTful API 기반 MC
3. 확장성 요구:
   • 높은 확장성: Microservices, Serverless
4. 실시간 처리:
   • 실시간 데이터: Event-Driven, CQRS

언어별 연산 속도

단순 연산 기준으로 나눠본 언어별 연산 속도 + 특징

Python

• 인터프리터 언어
• 연산 속도 : 1초에 1억
• C 기반의 확장 라이브러리(ex:Numpy)를 활용해 연산이 빠를 수 있음
• PyPy (JIT 컴파일러) 약 2~10배 빠름

JavaScript

• 인터프리터 언어
• 연산 속도 : 1초에 1억 ~ 5억
• JIT 컴파일러를 통해 연산속도 보완

Java

• 컴파일 언어
• 연산 속도 : 1초에 5억 ~ 10억
• Java는 JVM 위에서 실행되며, JIT컴파일링, 런타임 최적화 등이 있음, 기본 연산속도로 따졌을 때 Python보다 약 1020배, JavaScript보다 약 25배 빠름

C / C++

• 컴파일 언어
• 연산 속도 : 1초에 10억 ~ 50억
  • C와 C++은 컴파일 언어로, 코드가 기계어로 직접 변환되기에 가장 빠른 속도
• 하드웨어와 매우 가까운 수준에서 작업 가능

C#

• 연산 속도 : 1초에 5억 ~ 10억
• C#은 Java와 유사한 속도, .NET의 JIT 컴파일러와 런타임 최적화가 되어있음

PHP

• 인터프리터 언어
• 1초에 약 1억 ~ 2억
• C 기반으로 구현된 함수와 라이브러리를 호출

데이터 베이스 구현 언어

현재 주력 데이터베이스들인 MySQL, PostgreSQL, Oracle등 대부분의 데이터베이스는 C 또는 C++로 구현되어 있어 기계어에 가까운 최적화된 실행 성능을 갖고 있다.

정리

기본 연산속도가 가장 빠른 언어는 C, 그 외의 언어는 연산속도를 보장하기 위해 JIT 컴파일러, c언어 기반의 최적화된 라이브러리 등을 지원하여, 연산속도를 보완한다.

추가로 개발자들이 사용하는 것들(ex: MySQL, PHP, 파이썬 라이브러리)이 C 기반으로 만들어지는 이유를 추측하자면, 연산속도를 포함하여 low한 레벨에서 하드웨어에 가깝게 빠른 동작을 실행하려면 메모리, Disk I/O등 C언어 방식으로 직접 관리하는 것이 가장 최적화에 도움을 주는 방식이기 때문이 아닐까 생각된다.

Context Switching(문맥 교환)

병렬처리에 관해 이야기할 때 항상 등장하는 단어인 Context Switching에 대해 공부 해보았다. 해당 단어를 꺼내기 위해서는 기본적으로 알아둬야 할 사전지식이 필요하다. 해당 사전지식도 가볍게 다루며 콘텍스트 스위칭에 대하여 작성해보자.

프로세스

프로세스는 컴퓨터에서 프로그램이 실행될 때 사용되는 실행 단위로, 실행 중인 프로그램의 인스턴스다. 메모리와 CPU 자원을 할당받아 동작하는 상태를 의미하며, 우리가 코드를 통해 만든 하나의 애플리케이션이 실행될 때 생성된다.

멀티 프로세스, 멀티 스레드

• 멀티 프로세스는 여러 개의 독립된 프로세스를 생성하여 각각의 메모리 공간을 가지고 병렬로 동작
• 멀티 스레드는 하나의 프로세스 내에서 여러 스레드가 메모리 자원을 공유하며 동작

CPU의 동작

CPU는 하나의 프로세스만을 담당하는 것이 아니라, 컴퓨터에서 실행된 모든 프로그램의 동작을 담당해야 한다.

CPU는 여러 프로그램을 동시에 처리하는 것처럼 보이지만, 사실은 매우 짧은 시간 간격으로 각 프로세스의 작업을 번갈아가며 처리하고 있다. 이 때 각 프로세스는 자신이 중단된 지점의 상태, 즉 레지스터, 스택 포인터, 프로그램 카운터 등의 정보를 저장하고, 다른 프로세스의 상태를 불러와 실행을 이어간다. 이 정보를 Context(문맥) 라고 한다.

Context Switching(문맥 교환)

문맥 교환(Context Switching)은 여러 프로세스나 스레드가 CPU를 사용할 수 있도록 문맥을 저장하고 불러오는 작업을 의미한다. 이 과정에서 실행 중인 프로세스의 상태를 저장하고 다른 프로세스의 상태를 복원하는 작업이 필요하므로 일정한 오버헤드(비용) 가 발생한다. 따라서 병렬 처리를 통해 성능을 개선하려면, 문맥 교환의 빈도와 그로 인한 오버헤드가 전체 성능에 미치는 영향을 신중하게 고려해야 한다.

해시 - 솔트치기

이번 카카오페이 사건을 통해 대충만 알고있던 솔트에 대해 정리하는 시간을 가져봤다.

암호화를 했는데 왜 문제인가?

보도자료(상세) | 보도자료 | 보도·알림 |

카카오페이에서 외부 api(알리페이)와 통신할 때 사용자의 개인정보 값에 대한 암호화 처리를 제대로 하지 않았다.

보도자료의 랜덤값 없이 단순하게 해시처리(암호화) 라는 말은 암호화 작업을 하긴 했지만 암호화 작업의 기본인 랜덤값(솔트)을 넣지 않았다고 하는 것인데, 이 작업을 진행하지 않고 단순 해시처리를 한다면 레인보우 테이블 공격에 취약하다.

이번 주제에서 설명하는 해시(암호화)는 단방향 암호화인 MD5, SHA256 등의 암호화 즉 디코딩 할 수 없는 값을 기준으로 설명 할 것이다.

암호화 테스트 링크 : https://emn178.github.io/online-tools/sha256.html

해시

우리가 hello 를 회원가입 할 때 입력받아 암호화 하여 데이터베이스에 저장한다고 가정해보자.

회원가입 할 때 받은 비밀번호를 단순 해시화 하여 값을 저장했을 때

SHA256(hello) → 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 의 값으로 단방향 해시되어 데이터베이스에는 암호화 된 값을 저장할 것이다. 그래야 데이터베이스를 탈취당해도 유저의 실제 암호는 알 수 없기 때문인데

사실은 값을 찾아낼 수 있다.

레인보우 테이블

복호화를 하지 못하는데 값을 어떻게 찾을 수 있는지 의문이 들지만 해시된 값이 그저 단순 문자열로 이루어진 고정 값이라면 레인보우테이블 기법을 통해 해시된 값을 알아낼 수 있다.

레인보우 테이블이란 기존 문자들을 미리 암호화 처리하여 사전처럼 해시값 기준으로 원래의 문자열을 알아낼 수 있는 형태의 테이블이다.

레인보우 테이블이란 암호화된 해시값을 키로 두고, 키에 대한 원조 값을 찾아낼 수 있는 값을 value로 두는 사전이라고 볼 수 있는데 예시 테이블을 참고해서 보자면

만약 이러한 테이블을 저장한 레인보우 테이블이 있을 때 해커는 hello의 값을 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 해시 검색을 통해 알아낼 수 있을 것이다.

코드 예시

import java.util.*;

public class main
{
    public static void main(String[] args)
    {

                // 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824의 값이 저장됨
        String passwordSave = sha256("hello");

        //만들어져 있는 레인보우 테이블이라고 가정
        Map<String, String> rainbowTable = new HashMap<>();
        rainbowTable.put(sha256("hello"), "hello");

        //얻은 해시값
        System.out.println(rainbowTable.get("2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824"));
    }

    public static String sha256(String needEncodingString){
            //해싱처리
        //hello -> sha256 -> 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
        return "2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824";
    }
}

---------
출력 값 : hello

솔트 치기

솔트를 치는 이유는 보안 강화이며, 단순한 해시화는 앞에서 보았던 것 처럼 쉽게 예측이 가능한 것을 보았다.
해시작업을 할 때 기존의 문자열만으로 해시하는 것이 아니라 기존 문자열과 함께 서버에서만 알 수 있는 문자열을 부여해서 두 문자를 합친 해시값을 만드는 것이다.
예를 들면 sha256(hello + "qwerafaad" ) 와 같이 암호와 관련이 없는 문자열을 해시하기 전 추가해서 전혀 다른 해시값을 만드는 것이다. 이 때 암호와 관련이 없는 문자열을 솔트(소금)이라고 부른다.

또 솔트를 칠 때 주의해야 할 점이 있는데 이에 대해 알아보자

솔트값

소금 값은 짧지 않은 값으로 생성되어야 한다.
평범한 비밀번호로 구성되어있는 룩업 테이블(레인보우 테이블) 등의 경우 837G 만으로 전체 룩업 테이블을 구성할 수 있다. 이 837GB에서 “asd” 라는 문자가 추가되는 테이블을 만들었다고 했을 때 해커 입장에서는 부담스럽지 않은 값으로 해당 테이블의 조합을 만들어 낼 수 있을 것이다.

때문에 소금 값은 보통 해시 알고리즘을 사용해서 완성되는 해시길이로 생성한다.
ex ) SHA256 알고리즘은 32바이트 이기에 소금 값도 랜덤한 32바이트

유저별로 랜덤한 문자열을 생성

랜덤한 문자열을 만들어놓고 그 값을 그대로 재사용 해서는 안된다. 소금 값의 의미가 없어지는데, 예를 들어 하나의 유저의 비밀번호가 뚫렸다고 생각해보자

• “hello”(비밀번호) + “adad”(소금)

해커는 hello라는 비밀번호에 대해 adad의 소금 값을 알아냈다.

• 모든 유저의 비밀번호를 하나의 소금값으로 사용
• 비밀번호가 유출된 유저가 비밀번호 재설정을 했을 때

위의 두가지 상황에서 해커는 소금값을 알기 때문에 쉽게 찾아낼 수 있을 것이다.
위와 같은 이유로 소금을 칠 때는 반드시 두가지 규칙(짧지 않은 소금 값, 재사용 금지)을 따라야 한다.

정리하면 다음과 같다.

• 소금값(Salt) 생성
  • 사용자 계정을 생성하거나 비밀번호를 변경할 때, 새로운 임의의 랜덤 소금값을 생성합니다. 이 소금값은 절대 재사용하지 않으며, 충분히 길고 다양한 값을 가지도록 해야 한다. 일반적으로 소금값의 길이는 해시 함수의 출력 길이와 동일하게 해야한다.
• 비밀번호 해싱
  • 사용자가 입력한 비밀번호에 생성된 소금값을 추가(일반적으로 결합)한 후, 그 결합된 값을 해시 함수에 전달하여 해시된 비밀번호를 생성한다.
• 저장
  • 생성된 소금값과 해시된 비밀번호를 사용자 계정 테이블에 저장합니다. 이때 소금값은 별도로 저장되며, 해시된 비밀번호와 함께 보관.

참조

https://starplatina.tistory.com/entry/비밀번호-해시에-소금치기-바르게-쓰기

레인보우 테이블 : https://en.wikipedia.org/wiki/Rainbow_table

CGI(Common Gateway Interface)

서버 사이드에서 사용자의 프로그램을 동작하도록 하기 위한 프로토콜

CGI는 웹 서버에서 동적인 클라이언트의 요구에 응답하기 위해 만들어졌다.

CGI의 역할 및 흐름

• 보통의 경우 클라이언트가 HTTP요청을 했을 때 웹 서버에서는 요청이 백엔드 서버까지 들어가서 프로그램을 실행해야 하는지, 정적인 콘텐츠(html, css, js, image 등)만을 Response할지를 정함
• 로직 처리 프로그램에 넘겨야 한다면 서버에서 CGI프로토콜로 HTTP요청을 변환하여 백엔드 서버로 넘김
• 백엔드 서버에서 요청을 처리 후 CGI프로토콜로 서버에 Response 반환
• 상당히 많은 언어가 이러한 프로토콜(FastCGI API)을 지원 ( 파이썬, PHP, JAVA, Node.js 등 )

FastCGI

기존 CGI의 변형된 버전으로 주요 목적은 웹 서버와 CGI 프로그램 간 통신 시 발생되는 부하를 줄이며, 더 많은 요청을 관리할 수 있게 하는 것이다.

FastCGI 특징

• 여러 웹 서버들이 FastCGI를 구현하며, 다양한 언어로 만들어진 프로그램을 api호출할 수 있다
• Nginx같은 웹 서버들은 이 FastCGI통신을 하기 위해 게이트웨이 역할(프로토콜 변환)을 포함한다.

WebServer와의 상관관계

아래의 자료와 함께 Nginx Web Server를 예시로 설명을 하자면

1. 클라이언트가 웹 서버에 보내는 HTTP 또는 HTTPS 요청
2. Nginx에서 HTTPS요청이였다면 HTTP로 변환 후 FastCGI프로토콜로 다시 담아 FastCGI API를 지원하는 언어에 요청
3. 애플리케이션 프로그램은 요청된 로직을 처리 후 FastCGI 프로토콜로 Nginx측에 반환
4. Nginx는 응답받은 FastCGI 데이터를 HTTPS였다면 HTTPS로, HTTP였다면 HTTP로 반환
5. 통신 종료

정리

• 위에서 Nginx는 WS의 정적 페이지 반환, 게이트웨이 역할, FastCGI API와 연계하며 WAS의 역할을 모두 수행
• CGI, FastCGI는 웹 서버에서 사용 언어의 제약없이 통신에 활용할 수 있는 프로토콜
• 현 시점에서는 CGI가 아닌 FastCGI로 동적 데이터 처리를 주로 하고있음

출처 : https://ko.wikipedia.org/wiki/FastCGI

WebServer

웹 서버의 주요 기능

• 정적 콘텐츠 제공
  • HTML, CSS, JavaScript, 이미지파일 등과 같은 정적 파일을 클라이언트에게 제공하는 역할
  • 클라이언트가 URL을 통해 요청한 파일을 디스크에서 찾아 클라이언트에게 반환
• HTTP 요청 처리
  • 웹 서버는 클라이언트로부터 HTTP 요청을 받고 이에 대한 HTTP 응답을 반환
  • GET, POST, PUT, DELETE등 HTTP메서드를 처리
• 로드 밸런싱
  • 웹 서버는 여러 대의 서버에 요청을 분산시켜 처리 성능을 향상시키고 서버 과부하를 방지
• SSL/TLS 암호화
  • 웹 서버는 HTTPS를 통해 클라이언트와의 통신을 암호화하여 데이터의 기밀성과 무결성을 보호

Apach (1995)

• 기본적으로는 요청을 받기위한 프로세스가 생성되어있고, 프로세스를 미리 만들어두는 Prefork 방식을 사용.
• 새로운 요청이 들어올 때 미리 만들어 둔 프로세스를 가져다 사용하는 방식
• 만들어진 프로세스를 모두 사용하고 있다면 추가 프로세스를 만들어 할당
• 첫 도입 때부터 이용자가 상당히 많았지만 절대적인 컴퓨터를 사용하는 유저가 적어 프로세스 생성 형식이 문제가 없었지만, 컴퓨터의 보급이 많이 이뤄진 후에는 그만큼 많은 요청이 들어왔고 결국 C10K (Connection 10,000) 의 문제가 발생
• 많은 프로세스로 메모리 부족현상 발생

Nginx

• 트래픽이 많은 웹사이트의 WAS를 돕는 비동기 이벤트 기반 경량화 웹 서버
• WS의 역할만을 위해 활용되기도 하고, Reverse Proxy Server로 활용해 WAS의 부하를 줄일 수 있는 로드밸런서 역할도 가능
  • Reverse Proxy Server : 클라이언트가 리버스 프록시 서버에 요청하면 프록시 서버가 배후 서버(실제 응답서버)에서 데이터를 가져오는 형태
• C10K 문제 해결의 핵심은 비동기 이벤트 기반구조
• Nginx의 구조
  • 멀티 프로세스(master process)
    • master process는 서버의 설정, worker process를 관리하며 워커 프로세스의 생성, 관리 작업을 수행
  • 싱글 스레드(worker process)
    • 생성된 worker process에서는 각각 독립적으로 이벤트 루프 동작이 실행하며 루프의 큰 틀은 아래와 같음
      • 이벤트 감시
      • 이벤트 큐에 추가 : 이벤트 발생 시 이벤트 큐에 추가
      • 이벤트 처리 : 이벤트 큐에서 이벤트를 꺼내 non-blocking 비동기적으로 여러 요청을 수행
      • 반복

Nginx는 여러 프로세스를 사용하기 때문에 수 천개의 동시 연결을 처리할 수 있다.

우리가 알고있는 HTTP통신은 OSI 7계층의 응용계층에 속한다. 이 통신을 하기 위해 어떤 동작이 이루어지는지 키워드를 갖고 간단하게 다뤄보자

TCP(Transmission Controll Protocol)

TCP는 클라이언트와 서버간의 데이터 통신을 위해 사용하는 4계층에 속하는 프로토콜이다.
HTTP는 기본적으로 통신을 하기 위해 TCP를 활용해 3-way-handshake 과정을 거쳐 TCP 소켓 연결을 하고 데이터를 전송한다.이후 소켓 연결을 해제할 때는 4-way-handshake 과정을 거쳐 연결을 해제한다.

3-way-handshake

TCP통신은 기본적으로 3방향 핸드셰이크라는 방식으로 네트워크 소켓연결을 시도하는데
SYN → SYN-ACK → ACK 의 순서로 진행된다.

1. SYN(SYNchronize) : 클라이언트가 TCP SYN FLAG패킷을 서버로 송신
2. SYN-ACK(Synchronize-ACKnowledgement) : 서버는 SYN을 수신해 클라이언트에게 SYN-ACK를 송신
3. ACK(ACKnowledge) : 클라이언트에서 SYN-ACK를 수신하면 ACK를 서버에 송신

서버는 위의 과정을 거친 최종ACK를 수신받았을 때 TCP 소켓연결이 설정된다.

4-way-handshake

소켓연결 후 소켓을 끊을 때는 4-way-handshake 과정을 진행한다. 여기서 사용하는 주요 FLAG는 FIN, ACK이 있다.

해당 연결해제 절차는 클라이언트 측과 서버 측 모두 사용 가능하기에 A, B로 설명하자면,

1. A(FIN) → B
2. B(ACK) → A
3. B(FIN) → A
4. A(ACK) → B

위의 순서를 통해 A와 B의 소켓이 해제되는데 최초 (1)FIN요청을 받은 B는 A에게 (2)ACK신호를 줌과 동시에 연결을 끊는 작업을 시행하고 연결을 종료할 수 있는 준비작업이 완료되면 B가 A에게 최종종료되었다는 (3)FIN FLAG를 넘겨준다. 이를 받은 A는 최종확인 (4)ACK FLAG를 B에게 보냄으로써 소켓은 서로 닫히게 된다.

HTTP 통신

HTTP통신으로 호출하기 위한 흐름은 기본적으로 TCP 소켓 연결을 기본으로 소켓연결이 된 후 Request & Response작업이 진행된다.

때문에 순서를 다시한번 적자면 이렇게 된다

3-way-handshake → Request → Response → 4-way-handshake의 순서로 통신 흐름을 이해할 수 있다.

HTTPS 통신

우리가 평소에 사용하는 사이트들은 모두 HTTP가 아닌 HTTPS를 사용하고있다.
HTTPS는 Http에 S(Secure)가 붙어서 보안을 강화시킨 통신방식인데, 이 통신을 시행하면 중간에 데이터를 가로채가도 데이터는 암호화되어있기에 어떤 데이터를 가로챈건지 알 수 없게 되는 보안프로토콜이다.

이 통신방식은 Secure Sockets Layer(SSL)/Transport Layer Security (TLS) 등으로 불리우는 암호화 프로토콜통신(SSL Handshake, TLS Negotiation)을 HTTP통신의 데이터 교환에 앞서서 시행한다.

SSL Handshake, TLS Negotiation

이 통신을 SSL Handshake/TLS Negotiation이라고도 불리며, 기존의 소켓연결인 3-way-handshake 직후에 시행하는 통신작업인데, 순서는 다음과 같다.

1. Client → ClientHello → Server
2. Server → ServerHello → Client
3. Client → PremasterSecret → Server
4. Server → PremasterSecret(decrypt) → Client
5. HTTPS 통신가능

위의 과정을 거쳐 진행되고 전체 진행순서를 총 정리하면

3-way-handshake → SSL Handshake/TLS Negotiation(소켓 연결 완료) → Request → Response → 4-way-handshake(연결 해제)

의 순서가 된다.

출처 : https://sh-safer.tistory.com/146

https://velog.io/@dyunge_100/Network-TCPIP-4계층에-대하여

https://velog.io/@tess/아니-왜-http를-써요-tcp를-쓰지

https://brunch.co.kr/@sangjinkang/38

https://sooolog.dev/HTTP-통신과-TCP-통신-그리고-웹-소켓에-대한-기본-개념-정리/

얄코님 유튜브영상

• 익스플로러는 한동안 독과점을 한 채로 있었기에 국제 웹 표준을 지키지 않았다
• 때문에 호환이 잘 안된다

얄코님 유튜브영상

• 웹 프로그래밍 필수 html, css, js

뇌과학자님 유튜브영상

• 이해안되면 외워라
• 외우는게 때로는 정답