📬 통신 방식

(TCP, SOAP, GRPC, GraphQL, Websocket)

TCP(전송 제어 프로토콜)

: 두 개의 호스트를 연결하고 데이터 스트림을 교환하게 해주는 중요한 네트워크 프로토콜

• 역할: 에러가 없이 패킷이 신뢰할 수 있게 전달 되었는지 보증해 주는 것
• 데이터와 패킷이 보내진 순서대로 전달하는 것을 보장
• 동시제어가 가능하다.
  ->초기 요청이 작게 시작해도 컴퓨터들과 서버들의 대역폭의 깊이가 증가해도 네트워크가 지원할 수 있다는 뜻

TCP/IP

• 컴퓨터 사이의 통신 표준 및 네트워크의 라우팅 및 상호연결에 대한 자세한 규칙을 지정하는 프로토콜 스위트
  (인터넷에서 광범위하게 사용되며 이를 통해 학회, 대학, 정부, 기업에서 서로 통신 가능)

• 네트워크에 연결된 여러 컴퓨터(호스트) 사이의 통신을 허용
  -> 각 네트워크는 해당 네트워크의 호스트와 통신하는 다른 네트워크에 연결될 수 있다.

장점:

1. 네트워크 호환성 (Network Compatibility):

• TCP/IP는 다양한 하드웨어와 소프트웨어 플랫폼에서 작동
• 여러 종류의 네트워크와 호환성이 뛰어나다. 이는 다양한 환경에서 사용하기에 이상적이다.

2. 열린 표준 (Open Standards):

• TCP/IP는 개방적인 표준에 기반하고 있어 다른 제조사나 개발자들이 쉽게 준수하고 구현할 수 있다.
• 이로 인해 다양한 벤더와 개발자 간의 협력과 상호 운용성이 확보된다.

3. 스케일링 (Scalability):

• TCP/IP는 대규모 네트워크와 작은 규모 네트워크 모두에 적용 가능하다.
• 네트워크 크기의 확장성이 용이하다.
  -> 인터넷과 같이 급속하게 성장하는 네트워크에서 매우 중요하다.

단점:

1. 보안 취약성 (Security Vulnerabilities):

• TCP/IP는 초기 설계 당시에는 네트워크 보안을 고려하지 않았기 때문에, 보안 취약성이 존재한다.
  -> 이로 인해 해킹, 스푸핑, 덴니얼 오브 서비스 공격 등의 보안 문제가 발생할 수 있다.

2. 복잡성 (Complexity):

• TCP/IP는 많은 프로토콜과 서비스로 구성되어 있으며, 이를 관리하고 구성하는 것은 복잡할 수 있다.
• 특히 대규모 네트워크에서 관리하기 어려울 수 있다.

3. QoS (Quality of Service) 관리의 어려움:

• TCP/IP는 QoS를 관리하기 위한 제한된 메커니즘을 제공하지만, 실시간 응용 프로그램에 대한 강력한 QoS 관리가 부족할 수 있다.
  -> 이로 인해 실시간 통신에는 어려움이 있을 수 있다.

• 인터넷 프로토콜이 전송 단위를 정의하고 해당 전송 방법을 지정한다.
  -> TCP/IP는 정보를 연결하고 교환하는 많은 유형의 네트워크 기술을 허용,
  네트워크 하드웨어의 세부사항들을 숨길 수 있다.

• 인터넷 주소는 네트워크의 모든 머신이 네트워크상의 다른 머신과 통신할 수 있도록 한다.
  -> 또한 사용자가 필요로 하는 많은 통신 서비스에 대한 표준을 제공한다.

• 컴퓨터 시스템을, 네트워크에 접속하여 다른 인터넷 호스트와 통신할 수 있는 인터넷 호스트로 만드는 기능을 제공한다.

👨‍💼 명령과 기능

• 시스템 사이에서 파일 전송
• 원격 시스템에 로그인
• 원격 시스템에서 명령 실행
• 원격 시스템에 파일 인쇄
• 원격 사용자에 이메일 전송
• 원격 사용자와 대화식 통신
• 네트워크 관리

SOAP

(Simple Object Access Protocol)
: 웹 서비스 구현에서 구조화된 정보를 교환하기 위한 프로토콜

• SOAP은 메시지 전송을 위해 HTTP, SMTP, TCP 또는 다른 전송 프로토콜을 사용하며 메시지 형식으로 XML을 사용한다.
• SOAP은 과거에 웹 서비스 구축에 널리 사용되었지만 REST 및 gRPC와 같은 더 가벼운 대안으로 대부분 대체되었다.

gRPC

: Google에서 개발한 고성능 오픈 소스 RPC (원격 프로시저 호출) 프레임워크

• HTTP/2를 전송 프로토콜로 사용하며 인터페이스 정의 언어로 Protocol Buffers (protobuf)를 사용한다.
• gRPC는 효율적이고 확장 가능한 API를 구축하기 위한 것으로, 마이크로서비스 아키텍처 및 분산 시스템 간의 통신에 적합하다.

GraphQL

: API에 대한 쿼리 언어와 런타임을 제공하여 클라이언트가 필요한 데이터만 요청할 수 있게 한다.

• 기존 RESTful API 대비 클라이언트가 데이터를 정확하게 요청하고,
  여분이나 불필요한 데이터를 가져오지 않도록 하는 더 유연하고 효율적인 방법을 제공한다.
• GraphQL은 클라이언트가 데이터 요구 사항을 지정하고 단일 요청에서 여러 원본에서 데이터를 검색할 수 있게 한다.

WebSocket

: WebSocket은 단일 TCP 연결을 통해 전이중 통신 채널을 제공하는 프로토콜

• 클라이언트와 서버 간에 실시간, 양방향 통신을 가능하게 한다.
• WebSocket은 대화형 웹 애플리케이션, 온라인 게임, 채팅 애플리케이션 및 낮은 지연 통신이 필요한 기타 시나리오를 구축하는 데 주로 사용된다.

통신 방식의 동작 원리

파일(발신자):

• 통신의 시작점이며, 정보를 전송하고자 하는 측
• 정보를 생성하고, 필요한 형식으로 변환한 후, 전송 준비

파일(수신기):

• 정보를 수신하고자 하는 측
• 수신된 정보를 해석하고, 원래의 형식으로 복원하여 사용

파일(메시지):

• 정보의 형태로서, 텍스트, 음성, 이미지, 데이터 등 다양한 형태

채널(채널):

• 정보가 발신자에서 수신자로 전달되는 물리적인 경로 또는 통신 매체
• 채널은 유선 (예: 전화선, 광섬유) 또는 무선 (예: 무선 신호, 위성) 방식

파일 이름(인코딩):

• 발신자는 메시지를 채널을 통해 전송하기 위해 정보를 특정 형식으로 변환
  -> 이 변환 과정을 인코딩
  -> 주로 디지털 데이터가 아날로그 신호로 변환

송신 (변속기):

• 인코딩된 메시지는 채널을 통해 수신자로 전송
• 전송 과정에서 잡음이나 왜곡이 발생할 수 있으며, 이를 보정하는 기술도 사용

파일 이름(디코딩):

• 수신자는 전송된 메시지를 원래 형식으로 복원하기 위해 디코딩 과정을 수행
• 디지털 데이터를 디지털 신호로 다시 변환하거나, 아날로그 신호를 디지털 데이터로 변환하는 등의 과정이 포함될 수 있다.

의미해석inter(해석):

• 디코딩된 메시지는 수신자가 이해할 수 있는 형태로 해석되고 해석된 정보는 수신자에게 전달한다.

TCP를 채택한 이유에 대한 논리적인 설명

• TCP는 안정적이고 신뢰성 있는 데이터 통신을 위한 중요한 도구로 널리 채택된다.
  ex) 웹 브라우징, 이메일, 파일 전송, 스트리밍 등 다양한 네트워크 응용 프로그램에서 사용되고 있다.

---

📊 데이터 교환 방식

(SQRS, MQTT, AMQT ...)

SQRS (Sequential Request/Response Service):

• SQRS는 요청과 응답 사이의 순차적인 통신 패턴을 지원하는 프로토콜
• 클라이언트가 서버에 요청을 보내고,
  서버는 해당 요청에 대한 응답을 반환하는 방식으로 동작한다.
• 주로 실시간 통신이 필요한 시나리오나 요청-응답 패턴을 사용하는 응용 프로그램에서 사용한다.

MQTT (Message Queuing Telemetry Transport):

• MQTT는 경량 메시징 프로토콜로, Publish-Subscribe 메시징 패턴을 지원한다.
• 클라이언트가 특정 주제 (Topic)에 메시지를 발행(Publish)하고,
  해당 주제를 구독(Subscribe)하는 클라이언트는 해당 메시지를 수신한다.
• IoT (Internet of Things) 디바이스와 같이 대규모의 센서 데이터 수집 및 제어 시스템에서 주로 사용한다.

AMQP (Advanced Message Queuing Protocol):

• AMQP는 고급 메시지 큐 프로토콜로,
  메시지 큐 시스템에서 메시지를 전달하고 교환하는 데 사용한다.
• AMQP는 메시지 큐 시스템 간에 상호 운용성을 제공하며,
  다양한 메시지 패턴을 지원한다.
• 기업 환경에서 메시지 큐 시스템을 구축하고 다른 애플리케이션 간에 데이터를 안정적으로 전달하는 데 주로 사용한다.

SOA

SOA(service-oriented architecture)
: 서비스 인터페이스를 통해 소프트웨어 구성 요소의 재사용과 상호 운용성을 가능하게 하는 방법

• 서비스(Service)라고 불리는 독립적인 기능 단위를 중심으로 시스템을 설계한다.
  -> 서비스들을 조합하여 비즈니스 프로세스를 구축하고 실행한다.

• 서비스의 구현 방법을 거의 또는 전혀 모르더라도 호출이 가능하여 애플리케이션 간의 종속성을 줄여주는 느슨한 결합을 제공한다.

---

모놀리식 아키텍처

: 하나의 코드 베이스를 사용하여 여러 비즈니스 기능을 수행하는 전통적인 소프트웨어 개발 모델

• 모든 비즈니스 관련 사항을 함께 결합하는 하나의 코드 베이스를 갖춘 대규모의 단일 컴퓨팅 네트워크

• 이러한 종류의 애플리케이션을 변경하려면 코드 베이스에 액세스하고 서비스 측 인터페이스의 업데이트된 버전을 구축 및 배포하여 전체 스택을 업데이트한다.
  -> 업데이트에 제한이 많고, 시간이 오래 걸린다.

• 프로젝트 초기에는 코드 관리, 인지 오버헤드 및 배포의 용이성 면에서 모놀리스가 편리하다.
  -> 모놀리스에서 모든 것을 한꺼번에 릴리스할 수 있기 때문이다.

장점:

• 손쉬운 배포: 실행 파일 또는 디렉토리가 하나여서 배포가 더 쉽다.
• 개발: 하나의 코드 메이스로 애플리케이션을 구축하여 개발이 더 쉽다.
• 성능: 중앙 집중식 코드 베이스 및 리포지토리에서는 대부분 하나의 API만으로 마이크로서비스에서 여러 API가 수행하는 것과 동일한 기능을 수행 가능
• 테스트 간소화: 하나의 중앙 집중식 장치이므로 분산된 애플리케이션보다 엔드투엔드 테스트를 더 빠르게 수행
• 간편한 디버깅: 모든 코드가 한 곳에 있으므로 요청을 따라가서 문제를 찾기가 더 쉽다.

단점:

• 느린 개발 속도: 대규모 모놀리식 애플리케이션에서는 개발이 더욱 복잡해지고 속도가 느려진다.
• 확장성: 개별 컴포넌트를 확장할 수 없습니다.
• 안정성: 모듈에 오류가 있으면 애플리케이션 전체의 가용성에 영향을 준다.
• 기술 채택의 장벽: 프레임워크 또는 언어를 변경하면 애플리케이션 전체에 영향을 미치므로 변경 시 비용과 시간이 많이 소요되는 경우가 많다.
• 유연성 부족: 모놀리스의 경우 모놀리스에서 이미 사용한 기술로 제한
• 배포: 모놀리식 애플리케이션을 약간만 변경하는 경우에도 전체 모놀리스를 다시 배포해야 한다.

MSA

(MicroService Architecture)
: 작고, 독립적으로 배포 가능한 각각의 기능을 수행하는 서비스로 구성된 프레임워크

• 완전히 독립적으로 배포가 가능하다.

• 다른 기술 스택(개발 언어, 데이터베이스 등)이 사용 가능한 단일 사업 영역에 초점을 둔다.

• API를 통해서만 상호작용한다.
  -> 서비스의 end-point(접근점)을 API 형태로 외부에 노출하고, 실질적인 세부 사항은 모두 추상화한다.

• 내부의 구현 로직, 아키텍처와 프로그래밍 언어, 데이터베이스, 품질 유지 체계와 같은 기술적인 사항들은 서비스 API에 의해 철저하게 가려진다.

MSA의 장단점

장점:

• 모듈성과 유연성 (Modularity and Flexibility):
  각 마이크로서비스는 독립적으로 개발, 배포, 확장 및 유지보수
  -> 애플리케이션의 모듈성과 유연성이 향상

• 독립적인 스케일링 (Independent Scaling):
  마이크로서비스는 개별적으로 스케일링할 수 있다.
  -> 특정 서비스의 부하가 증가해도 전체 애플리케이션을 확장할 필요가 없다.

• 기술 다양성 (Technology Diversity):
  서비스 간에 기술 스택을 다르게 사용할 수 있다.
  -> 최적의 기술을 선택하여 개발할 수 있습니다.

• 빠른 개발과 배포 (Rapid Development and Deployment):
  각 마이크로서비스는 작고 단순하기 때문에 개발 및 테스트가 빠르게 이루어질 수 있다.
  -> CI/CD (Continuous Integration/Continuous Deployment) 파이프라인을 쉽게 구축할 수 있다.

• 장애 격리 (Fault Isolation):
  하나의 서비스의 장애가 다른 서비스에 영향을 미치지 않도록 설계
  -> 시스템의 신뢰성을 향상시킨다.

• 팀 규모와 독립성 (Team Size and Autonomy):
  작은 팀이 각각의 마이크로서비스를 관리하고 개발 가능하다.
  -> 팀 간 독립성이 보장된다.

단점

• 복잡성 (Complexity):
  서비스 간 통신과 데이터 일관성 유지를 위한 복잡한 로직이 필요하며, 이로 인해 전체 시스템의 복잡성이 증가할 수 있다.

• 운영과 모니터링 어려움 (Operational and Monitoring Challenges):
  다수의 서비스를 운영하고 모니터링하는데 필요한 인프라와 도구에 대한 투자가 필요하며, 전체 시스템의 상태를 파악하기 어려울 수 있다.

• 트랜잭션 관리 (Transaction Management):
  여러 서비스 간의 트랜잭션 관리가 복잡하며, 일관성을 유지하기 위한 노력이 필요하다.

• 보안 및 인증 (Security and Authentication):
  서비스 간의 보안 및 인증 문제를 처리해야 하며, 이로 인한 추가 복잡성이 발생할 수 있다.

• 데이터 일관성 (Data Consistency):
  분산 데이터 관리로 인해 데이터 일관성 유지가 어려울 수 있다.
  -> 이를 해결하기 위한 전략이 필요합니다.

• 통합 테스트 (Integration Testing):
  서비스 간 통합 테스트가 복잡하고 시간이 오래 걸릴 수 있다.

---

💻 OSI 7계층

1. 물리 계층 (Physical Layer):

• 물리적인 하드웨어와 전송 매체를 다루는 계층
• 데이터를 비트 스트림으로 변환하고, 전송 매체를 통해 전송한다.
• 전기적, 기계적, 광학적 특성을 다룬다.

2. 데이터 링크 계층 (Data Link Layer):

• 물리 계층에서 오는 비트들을 프레임(Frame)으로 그룹화하고, 에러 감지 및 수정을 수행한다.
• 주소 지정과 흐름 제어도 수행한다.
• 이더넷, Wi-Fi와 같은 로컬 네트워크 기술에서 활용한다.

3. 네트워크 계층 (Network Layer):

• 데이터 패킷의 라우팅과 전송 경로 선택을 담당한다.
• IP 주소와 라우팅 프로토콜을 사용하여 패킷의 목적지를 결정한다.
• 라우터가 이 계층에서 동작한다.

4. 전송 계층 (Transport Layer):

• 송신자와 수신자 간의 연결을 관리하고, 데이터 전달을 확인하며, 에러 복구를 수행한다.
• 주로 TCP (Transmission Control Protocol)와 UDP (User Datagram Protocol)를 사용한다.

5. 세션 계층 (Session Layer):

• 데이터 교환의 세션 관리와 동기화를 담당한다.
• 세션 설정, 유지 및 종료를 처리한다.

6. 표현 계층 (Presentation Layer):

• 데이터의 형식을 변환하고, 데이터 암호화 및 복호화를 수행한다.
• 데이터의 표현 형식 (예: 압축, 암호화)을 관리한다.

7. 응용 계층 (Application Layer):

• 최종 사용자와 상호 작용하는 응용 프로그램에 서비스를 제공한다.
• 프로토콜 스택의 가장 상위에 위치하며, 이메일, 웹 브라우징, 파일 전송 등의 응용 프로그램과 상호 작용한다.

---

TCP

(3way handshaking, sign, ack, fin...)

TCP

: 인터넷에서 데이터를 안정적으로 전송하기 위한 프로토콜

• 여러 단계의 핸드셰이킹 및 컨트롤 메시지를 사용하여 연결 설정, 데이터 전송 및 연결 종료를 수행한다.

3-way Handshaking (연결 설정)

• TCP 연결을 설정하기 위한 초기 핸드셰이킹 과정
• 클라이언트는 서버에게 SYN(Synchronize) 패킷을 보낸다.
• 서버는 SYN을 받고, 이에 대한 응답으로 SYN-ACK(Synchronize-Acknowledge) 패킷을 보낸다.
• 클라이언트는 서버의 SYN-ACK를 받고 ACK(Acknowledge) 패킷을 보내 연결을 확립한다.
  -> 이 과정을 통해 양쪽 간에 신뢰성 있는 연결이 설정된다.

---

1. 1단계(SYN): 클라이언트는 SYN(동기화) 플래그가 설정된 TCP 패킷을 서버로 전송하여 연결을 설정하기 위한 초기 요청을 나타낸다.

2. 2단계(SYN-ACK): 서버는 SYN 패킷을 수신하고 SYN 및 ACK(승인) 플래그가 모두 설정된 패킷을 보내 연결을 설정할 준비가 되었음을 나타낸다.

3. 3단계(ACK): 클라이언트는 SYN-ACK 패킷을 수신하고 확인 응답(ACK) 패킷을 서버로 다시 보낸다.
   -> 이렇게 하면 연결 설정이 완료되고 데이터 전송을 시작한다.

ACK(승인):

• ACK 플래그는 TCP 패킷에서 데이터 수신을 확인하는 데 사용한다.

• 파티는 데이터를 수신하면 ACK 패킷을 보낸 사람에게 다시 전송하여 데이터가 성공적으로 수신되었음을 확인
  -> 이 메커니즘은 신뢰할 수 있는 데이터 전송을 보장한다.

FIN(마무리):

• FIN 플래그는 TCP 연결 종료를 시작하는 데 사용
  -> 한 당사자(클라이언트 또는 서버)가 연결을 닫기로 결정하면 연결 종료 의사를 알리기 위해 FIN 플래그가 설정된 TCP 패킷을 보낸다.

• 상대방이 ACK 패킷과 자신의 FIN 패킷으로 응답하거나, 양쪽이 연결을 닫기로 합의할 때까지 데이터를 계속 전송할 수 있다.

TCP의 장단점

장점:

1. 신뢰성 (Reliability):

• TCP는 데이터 전송의 신뢰성을 보장한다.
• 데이터 패킷을 보내고, 수신 확인을 기다린 후에만 다음 패킷을 전송하므로 데이터 손실을 최소화한다.

2. 순서 보장 (Order Preservation):

• TCP는 데이터 패킷을 전송한 순서대로 수신측에 전달한다.
• 이로써 수신측에서는 데이터 패킷의 순서를 복구하기 위한 추가 노력이 필요하지 않는다.

3. 흐름 제어 (Flow Control):

• TCP는 수신측의 버퍼 상태를 고려하여 데이터의 전송 속도를 조절한다.
• 과도한 데이터의 전송으로 인한 오버플로우를 방지한다.

4. 오류 검출 및 복구 (Error Detection and Recovery):

• TCP는 체크섬(Checksum)과 시퀀스 번호를 사용하여 데이터의 정확성을 검사한다.
• 필요한 경우 재전송을 수행하여 데이터 오류를 최소화한다.

5. 혼잡 제어 (Congestion Control):

• TCP는 네트워크 혼잡을 감지하고 전송 속도를 조절하여 네트워크의 과도한 혼잡을 방지한다.

6. 멀티플렉싱 및 디멀티플렉싱 (Multiplexing and Demultiplexing):

• TCP는 다중 연결을 관리하고 여러 애플리케이션 간에 데이터를 구분하기 위한 포트 번호를 사용한다.

7. 웹 브라우징 및 이메일과 같은 응용 프로그램에 적합 (Suitable for Applications like Web Browsing and Email):

• TCP는 웹 브라우징, 이메일, 파일 전송 등과 같은 응용 프로그램에서 사용하기에 적합하다.

단점:
1. 설정 지연 (Connection Establishment Overhead):

• TCP 연결 설정의 3-way 핸드셰이킹 과정은 설정 지연을 유발할 수 있다.
  -> 이는 일부 응용 프로그램에서 문제가 될 수 있다.

2. 데이터 전송 속도의 한계 (Limited Data Transfer Speed):

• TCP는 데이터 신뢰성을 위해 오버헤드를 발생시키므로 빠른 데이터 전송 속도를 제한할 수 있다.

3. 비디오 스트리밍 및 실시간 응용 프로그램에는 적합하지 않음 (Not Suitable for Video Streaming and Real-time Applications):

• TCP는 실시간 통신 및 비디오 스트리밍과 같이 지연 시간이 중요한 응용 프로그램에는 적합하지 않을 수 있다.

4. 데이터 전송 중단 (Connection Termination Overhead):

• 연결 종료 과정에서도 오버헤드가 발생, 이로 인해 일부 애플리케이션에서 지연이 발생할 수 있다.

5. 데이터 멀티캐스팅의 한계 (Limitations in Data Multicasting):

• TCP는 데이터 멀티캐스팅을 지원하지 않으므로, 멀티캐스트 통신에는 적합하지 않는다.

UDP

: 네트워크 통신에서 사용되는 전송 계층 프로토콜 중 하나
(EX. 특히 비디오 재생 또는 DNS 조회와 같이 시간에 민감한 전송을 위해 인터넷을 통해 사용)

작동

: UDP는 네트워크의 두 컴퓨터 간에 데이터를 전송하기 위한 표준화된 방법

• 다른 프로토콜과 비교하여 UDP는 먼저 연결을 설정하거나, 해당 패킷의 순서를 표시하거나, 의도한 대로 도착했는지 여부를 확인하지 않고,
  -> 패킷(데이터 전송 단위)을 대상 컴퓨터로 직접 보내는 간단한 방식으로 이 프로세스를 수행 (UDP 패킷을 '데이터그램'이라고 합니다.)

• UDP는 데이터를 신속하게 전송하기 위한 경량 프로토콜
  -> 데이터 전달의 신뢰성과 순서를 보장하지 않는다.

• 데이터를 빠르게 전송하고자 할 때 사용한다.

• 데이터의 완전한 신뢰성보다는 속도가 중요한 상황에서 유용하다.

• 그러나 데이터의 손실이나 재전송에 대한 처리가 필요한 경우에는 TCP와 같은 다른 전송 계층 프로토콜을 고려해야 한다.

TCP vs UDP

TCP (Transmission Control Protocol):

1. 신뢰성 (Reliability):

• TCP는 데이터의 신뢰성을 보장한다.
• 데이터가 손실되거나 손상될 경우, 다시 전송하고 순서를 다시 조립하여 오류를 최소화한다.

2. 순서 보장 (Order Preservation):

• TCP는 데이터를 송신한 순서대로 수신측에 전달한다.
  -> 따라서 데이터의 순서가 중요한 응용 프로그램에 적합하다.

3. 흐름 제어 (Flow Control):

• TCP는 수신측의 버퍼 상태를 고려하여 데이터의 전송 속도를 조절하며, 오버플로우를 방지한다.

4. 연결 지향 (Connection-Oriented):

• TCP는 연결을 설정하고 연결 상태를 유지한 후에 데이터를 전송한다.
• 연결 설정 및 해제에 대한 오버헤드가 있습니다.

5. 데이터 전송 지연 (Latency):

• TCP는 신뢰성을 보장하기 위해 추가적인 핸드셰이킹 및 재전송을 수행하므로 일부 지연이 발생할 수 있다.

6. 웹 브라우징, 이메일, 파일 전송과 같은 응용 프로그램에 적합:

• 신뢰성이 중요한 응용 프로그램에 적합하다.

UDP (User Datagram Protocol):

1. 신뢰성 부족 (Unreliable):

• UDP는 데이터 전송의 신뢰성을 보장하지 않는다.
• 데이터가 손실될 수 있고, 순서가 바뀔 수 있다.

2. 순서 보장 부족 (Order Preservation):

• UDP는 데이터를 전송한 순서대로 보장하지 않는다.
• 데이터 순서가 중요하지 않은 경우에 사용된다.

3. 흐름 제어 부족 (No Flow Control):

• UDP는 흐름 제어를 수행하지 않으므로 과도한 데이터 전송으로 인한 오버플로우 방지가 필요하다.

4. 비연결 지향 (Connectionless):

• UDP는 연결 설정 과정이 없으며, 데이터를 즉시 전송한다.
• 연결 설정 및 해제 오버헤드가 없다.

5. 데이터 전송 지연 최소화 (Low Latency):

• UDP는 추가적인 신뢰성 보장을 위한 오버헤드가 적으므로 데이터 전송 지연이 낮다.

6. 실시간 응용 프로그램, 비디오 스트리밍, 멀티캐스팅에 적합:
   낮은 지연 시간과 빠른 데이터 전송이 필요한 응용 프로그램에 적합하다.

=> 데이터의 신뢰성과 순서가 중요한 경우에는 TCP를 선택하고,
데이터 전송 속도와 지연 시간이 중요한 경우에는 UDP를 선택하는 것이 일반적

-> 응용 프로그램의 요구 사항 및 네트워크 조건을 고려하여 프로토콜을 선택해야 한다.

• 때로는 두 프로토콜을 혼합하여 사용하기도 한다.

📗 + node.js - javascript

javascript

: 웹 페이지에서 복잡한 기능을 구현할 수 있는 스크립팅 또는 프로그래밍 언어
(브라우저, 문서 등을 다루는, client에 대한 개발을 하는 도구)

• 1. HTML:

  • 문단, 제목, 데이터 표를 정의하거나 페이지에 이미지와 동영상을 삽입하는 등 웹 콘텐츠를 구성하고 의미를 부여하는 데 사용하는 마크업 언어

• 2. CSS:

  • 배경색과 글꼴을 설정하고 콘텐츠를 여러 열에 배치하는 등 HTML 콘텐츠에 스타일을 적용하는 데 사용하는 스타일 규칙 언어

• 3. JavaScript:

  • 동적으로 변경되는 콘텐츠를 만들고, 멀티미디어를 제어하고, 이미지에 애니메이션을 적용하는 등 거의 모든 작업을 수행할 수 있는 스크립팅 언어
    (JavaScript는 표준 웹 기술이라는 케이크의 세 번째 층)

node.js

: Chrome V8 JavaScript 엔진으로 빌드 된 JavaScript 런타임
(backend에서 server에 대한 개발을 하는 도구)

• 확장성이 있는 네트워크 어플리케이션 개발에 사용되는 소프트웨어 플랫폼이다. 특히 서버사이트에서 많이 사용

• 브라우저 위라는 제한된 환경에서만 움직이던 JavaScript를 Python이나 Ruby와 같이 브라우저 위에서 움직이도록 해주는 것

• JavaScript으로 OS의 기능에 액세스하는 프로그램을 짤 수 있다. 즉, 브라우저에서 동작하고 있을 때는 되지 않았던 자유로운 파일의 읽기 쓰기나 네트워크 통신 등의 OS의 기능을 다룰 수 있다.

node.js - javascript 차이점

JavaScript

• 프로그래밍 언어
• 브라우저에서만 동작
• client에 대한 개발이 가능

Node.Js

• 브라우저 밖에서 동작하는 Javascript 런타임
• 데크스탑에서 동작
• Express와 같은 라이브러리를 사용하여 js언어로 웹서버 구축이 가능

( 런타임(영어: runtime→실행시간):
컴퓨터 과학에서 컴퓨터 프로그램이 실행되고 있는 동안의 동작 )

참고사이트
MDN: https://developer.mozilla.org/ko/docs/Web/JavaScript
NodeJs: https://nodejs.org/ko/docs

• https://hazel-developer.tistory.com/152
• https://velog.io/@bleach7/Javascript%EC%99%80-Nodejs%EA%B0%80-%EC%96%B4%EB%96%BB%EA%B2%8C-%EB%8B%A4%EB%A5%B8-%EA%B2%83%EC%9D%B8%EC%A7%80-%EC%84%A4%EB%AA%85%ED%95%B4%EC%A3%BC%EC%84%B8%EC%9A%94