1️⃣OSI 7계층
: 국제 표준화 기구에서 네트워크 통신이 이뤄지는 과정을 7단계로 나눈 네트워크 표준 모델
- 송신부: 데이터 송신 시 높은 계층->낮은 계층으로 전달 <-> 수신부: 데이터 송신 시 낮은 계층->높은 계층으로 전달
- 데이터 캡슐화: 데이터 송신 시 각 계층에서 필요한 정보를 추가(제어 정보를 담은 헤더 or 트레일러)해 데이터를 가공하는 과정 -> 수신부의 같은 계층에서 데이터 호환성을 높이고 오류의 영향을 최소화하기 위해!
- 송신부에서 데이터 캡슐화를 거친 결과물을 수신부로 보내면, 수신부는 헤더와 트레일러를 분석해 제거하는 역캡슐화 진행
- 프로토콜(=통신규약): 데이터를 송수신하기 위해 정한 규칙.
(1) 1계층(물리 계층): 데이터를 비트 단위로 변환 후 전송하거나 전기 신호를 데이터로 복원 / 장비: 리피터, 허브
(2) 2계층(데이터 링크 계층): 데이터의 흐름 관리, 오류 검출 및 복구 / 장비: 브리지, 스위치, 이더넷
(3) 3계층(네트워크 계층): 데이터를 송신부에서 수신부까지 보내기 위한 최적인 경로를 선택하는 라우팅 수행. 이때 최적 경로 = 라우트 / 장비: 라우터
(4) 4계층(전송 계층): 신뢰성 있는 데이터를 전달하기 위한 계층. TCP, UDP 같은 전송 방식과 포트 번호 등을 결정.
(5) 5계층(세션 계층): 세션의 유지 및 해제 등 응용 프로그램 간 통신 제어와 동기화
(6) 6계층(표현 계층): 데이터를 표준화된 형식으로 변경
(7) 7계층(응용 계층): HTTP, FTP 등의 프로토콜을 응용 프로그램의 UI를 통해 제공
2️⃣ TCP/IP 4계층
: TCP/IP에 맞춰 OSI 7계층을 단순화한 것
- TCP(전송 제어 프로토콜): 패킷(데이터를 나눈 단위. 데이터의 송신 주소, 수신 주소 등의 정보 포함)의 전달 여부와 전송 순서를 보장하는 통신 방식
- IP(인터넷 프로토콜): 패킷을 빠르게 보내기 위한 통신 방식
- IP 주소: IP에서 컴퓨터 또는 네트워크 장치를 식별하기 위한 값. 어떤 네트워크에 속해있는지, 어떤 기기인지 확인 가능
(1) 1계층(네트워크 인터페이스 계층): =네트워크 접근 계층. 데이터를 전기 신호로 변환, MAC 주소(하드웨어 고유의 주소)를 사용해 기기에 데이터 전달. 프로토콜: 이더넷, Wi-Fi
(2) 2계층(인터넷 계층): 프로토콜: IP / 전송 계층으로부터 받은 데이터에 헤더를 붙여 캡슐화 -> 패킷 or 데이터그램
(3) 3계층(전송 계층): 포트 번호로 데이터를 적절한 응용 프로그램에 전달. 데이터 단위: 세그먼트 / 프로토콜: TCP, UDP
3️⃣ TCP(Transmission Control Protocol)
: 전송 계층에 해당하는 네트워크 프로토콜. 연결형 서비스를 지원하고 데이터의 신뢰성을 보장.
- 송신부와 수신부의 연결을 확인(이 둘은 1:1 통신을 함)
- 패킷 교환 방식은 가상 회선 방식(패킷이 전달되는 회선이 정해져 있음)
- 패킷의 전송 순서가 보장됨
- 패킷의 수신 여부 확인
- 데이터 손실이 없음을 보장 -> 신뢰성 높음
- 데이터의 송수신 속도가 느림
4️⃣ TCP 핸드셰이킹
- TCP에서 송신부와 수신부 연결 시작 -> 3 way 핸드셰이킹 / 연결 종료 -> 4 way 핸드셰이킹
- 이 과정에서 연결을 제어 및 관리하도록 플래그(SYN, FIN, ACK 등) 값을 주고 받음
- 3 way 핸드셰이킹: 데이터를 본격적으로 주고받기 전에 상대방 컴퓨터와 세션을 수립하는 과정. 데이터의 정확한 전달을 위해 필요!
- 3 way 핸드셰이킹 과정
(1) 송신부가 수신부와 연결하기 위해 [SYN 메세지+ 임의의 숫자 N]를 보냄 --- 송신부 SYN_SENT
(2) 수신부가 메세지를 받고 [ACK 메세지+(N+1)+M]를 전송해 연결 요청을 수락함. --- 수신부 SYN_RECEIVED
(3) 송신부가 메세지를 받고 [ACK 메세지 + (M+1)]를 전송 --- 송신부 ESTABLISHED -> 받은 수신부 --- ESTABLISHED
- 4 way 핸드셰이킹: TCP 연결을 해제할 때 이뤄지는 과정
- 4 way 핸드셰이킹 과정
(1) 송신부가 수신부와의 연결을 종료하기 위해 FIN 메세지 전송 --- 송신부 FIN_WAIT1
(2) 수신부가 메세지를 받고 ACK 메세지 전송 --- 수신부 CLOSE_WAIT -> 연결을 종료하기 위한 작업 -> 받은 송신부 --- FIN_WAIT2
(3) 수신부에서 연결 종료 준비 끝나고 송신부에 FIN 메세지 전송 --- LAST_WAIT
(4) 받은 송신부는 ACK 메세지 전송 --- 송신부 TIME_WAIT ---잠시 후--- CLOSED -> 받은 수신부 --- CLOSED
5️⃣ TCP 제어 방법
- 흐름 제어: 데이터 송신부와 수신부에서 데이터 처리 속도의 차이 때문에 생기는 데이터 손실을 방지하는 방법
(1) 정지-대기: 송신부에서 데이터를 보낸 후 수신부로부터 ACK 메세지를 받을 때까지 다음 데이터를 보내지 않고 기다리는 방식 -> 시간 면에서는 비효율적
(2) 슬라이딩 윈도우: 송신부에서 데이터의 수신 여부를 확인하지 않고 수신부에서 설정한 윈도우 크기만큼 데이터를 연속적으로 보낼 수 있게 해서 데이터의 흐름을 동적으로 제어하는 방식. 윈도우 크기 = 응답받지 않고도 보낼 수 있는 데이터의 최대 개수. 윈도우 크기는 3 - way 핸드셰이킹 과정에서 정해짐. -> 정지-대기의 단점 보완!
(3) 혼잡 제어: 송신부의 데이터 전달 속도와 네트워크 속도 차이로 데이터 손실이 발생하는 것을 방지하기 위한 방법. 네트워크에 패킷이 쌓이면서 응답을 받지 못함->메세지 전송 실패로 패킷 재전송->혼잡 가중->악순환
a. ALMD: 데이터 전달시 합 증가 방식으로 혼잡 윈도우의 크기를 더해가면서 키움. <-> 데이터 손실이 발생하면 혼잡 윈도우의 크기를 곱 감소 방식으로 배수 단위로 줄임. -> 시간이 지나면 네트워크 대역폭을 공평하게 사용할 수 있지만, 증가폭 대비 감소폭이 커서 그 때까지 시간이 오래 걸림.
b. 느린 시작: 윈도우 크기가 1인 상태에서 시작해 ACK 메세지를 수신할 때마다 크기를 1씩 늘려나감. 그러다 혼잡 발생 시 1로 확 줄이는 방식. 보낼 수 있는 패킷 수가 지수 함수 형태로 증가. -> ALMD 방식이 초기에 전송 가능한 패킷 수가 적다는 단점 보완
c. 혼잡 회피: 윈도우 크기가 지수 함수 형태로 증가하다가 혼잡이 발생하는 것을 방지하기 위해 윈도우 크기에 대한 임계점을 정하는 방식.
d. 빠른 회복: 혼잡 발생 시 혼잡 윈도우 크기를 절반으로 줄이고 선형적으로 증가하는 방식
e. 빠른 재전송: Duplicate ACK(못 받은 패킷 송신부에 재요청) 3번 발생 시 해당 시점의 윈도우 크기를 반으로 줄이는 방식. 이후 ACK 메세지를 받으면 다시 윈도우 크기를 키움.
(4) 오류 제어: 데이터에 오류 or 유실이 발생할 때(NAK(잘못된 데이터 응답)메세지, 3 Duplicate ACK, ACK를 받지 못해 타임아웃 발생)데이터의 신뢰성을 보장하기 위해 오류를 제어하는 방식
a. 정지-대기: 송신한 패킷에 대한 ACK 메세지를 일정 시간 받지 못해 타임아웃 발생 -> 해당 패킷을 다시 보내는 방식. -> 데이터 유실 간단히 처리 but 하나만 보내고 기다려야 하므로 ARQ 방식(재전송 요청) 사용
b.Go-Back-N ARQ: 송신부에서 연속적으로 데이터를 보냈을 때 누락된 데이터가 있으면 송신부에서 해당 데이터부터 재전송하는 방식.
c. Selective-Repeat ARQ: 송신부에서 연속적으로 데이터를 보냈을 때 누락된 데이터가 있으면 수신부에서 해당 데이터만 재전송을 요청하는 방식 -> 효율적으로 보이지만 받은 패킷을 재정렬하는 로직이 추가로 필요
6️⃣ UDP(User Datagram Protocol)
: 송신부와 수신부 간 연결을 지원하지 않고 데이터그램 형태의 통신을 지원 -> 3-way 핸드셰이킹 같은 과정 없이 패킷을 바로 송수신 -> 신뢰성이 낮지만 속도가 빠름!
- 송신부와 수신부의 연결이 보장되지 않는 비연결형 서비스
- 패킷이 서로 다른 회선으로 교환될 수 있는 데이터그램 패킷 교환 방식
- 송신부에서 전달한 패킷 순서와 수신부에서 받은 패킷 순서가 다를 수 있음
- 패킷의 수신 여부를 확인하지 않음
- 1:1 통신, 1:N 통신, N:N 통신 모두 가능
- 최소한의 신뢰성을 보장하기 위해 체크섬 방식으로 오류 검출
+ 체크섬 방식: UDP의 헤더, IP 헤더의 일부 정보와 데이터로 체크섬 값을 생성 -> UDP 헤더의 체크섬 영역에 넣어 수신부에 보냄 -> 체크섬을 포함한 모든 값을 더해 비트가 모두 1이 나오는지 확인( 송신부와 동일한 체크섬 값이 나오는지 확인) -> 값을 더해 확인하는 방식이라 오류 100% 검출 불가 + 체크섬은 선택사항
7️⃣ HTTP(Hypertext Transfer Protocol)
: 인터넷상에서 데이터를 전송하기 위한 프로토콜
- 비연결성: 클라이언트에서 요청을 보낸 후 서버로부터 응답을 받으면 연결을 끊는 것 -> 자원을 아낄 수 있음! but 서버가 클라이언트 기억x, 연속적으로 요청시 연결/해제 반복하므로 자원 낭비 -> HTTP Keep Alive로 일정 시간 동안 연결 유지
- 무상태: 서버에서 클라이언트의 상태를 저장하지 않음(이전에 요청한 사항을 서버에 저장하지 않음) -> 쿠키 or 세션으로 데이터 저장! 서버 확장성이 높다는 장점(클라이언트의 요청에 응답하는 서버가 바뀌어도 되기 때문에 서버 계속 확장 가능)
+ 쿠키: 클라이언트의 로컬 웹 브라우저에 저장하는 데이터 파일 ex) 로그인 정보, 장바구니
+ 세션: 서버에서 클라이언트와의 연결 정보를 저장 및 관리. 보안은 쿠키보다 좋지만 서버에 과부하 가능성 있음
- HTTP 메서드: POST(생성), GET(조회), PUT(전체 갱신), DELETE(제거), PATCH(일부 갱신)
- HTTP 메세지의 구조
(1) 요청 라인: 요청 url, 요청 방법, HTTP 버전 등
(2) 상태 라인: 요청에 대한 HTTP 상태 코드, HTTP 버전 등
(3) 헤더: 키-값으로 구성된 다수의 헤더 항목
(4) 빈 줄: 헤더와 바디 구분(헤더의 끝)
(5) 바디: POST인 경우에만 존재. 그 외에는 공백
- HTTP 상태 코드: 클라이언트의 요청에 대한 서버의 상태를 알려 주는 코드. 코드의 시작 숫자로 의미를 알 수 있음
(1) 1XX: 클라이언트로부터 요청을 받아 처리 중
(2) 2XX: 요청을 성공적으로 처리함
(3) 3XX: 요청을 처리하기 위해 추가 처리 필요
(4) 4XX: 클라이언트 오류(401: 인증되지 않음 / 404: 요청한 자원을 찾지 못함)
(5) 5XX: 서버 오류
8️⃣ HTTPS(Hypertext Transfer Protocol Secure)
: 보안 계층인 SSL/TLS를 이용해 HTTP의 보안을 강화한 웹 통신 프로토콜. 데이터 암호화를 거치지 않고 전송하는 HTTP의 단점 보완.
- SSL(Secure Socket Layer) 단점 보완해 개발된 TLS(Transport Layer Security)
- HTTP와의 차이점은 보안 계층이 추가된 것. 데이터 송신 시 응용 계층에서 보안 계층의 SSL/TLS로 데이터를 보내면 암호화를 시켜 전송 계층으로 전달 -> 데이터 수신 시 전송 계층에서 보낸 데이터를 SSL/TLS에서 복호화 한 후 응용 계층으로 전달
(1) 대칭 키 암호화 방식: 암호화와 복호화에 모두 같은 키인 대칭 키 이용. -> 유출 주의!
(2) 공개 키 암호화 방식: 암호화와 복호화를 다른 키로 하는 방식. 암호화는 공개 키로, 복호화는 비밀 키로
9️⃣ 웹페이지 접속 과정
(1) 사용자가 URL을 웹 브라우저에 입력함
(2) 웹 브라우저는 이 URL을 바탕으로 DNS 서버에 연결할 IP 요청
(3) DNS 서버는 IP 주소를 웹 브라우저에게 제공
(4) 웹 브라우저는 IP를 통해 웹 서버와 TCP/IP 연결을 한 후 HTTP 요청을 보냄
(5) 웹 서버는 받은 HTTP 요청에 웹 페이지와 필요한 리소스로 응답
(6) 웹 브라우저는 받은 응답을 바탕으로 사용자에게 웹 페이지를 보여줌
🔟 REST(Representational State Transfer)
: HTTP 통신을 활용하기 위해 고안된 아키텍처. 클라이언트는 URI로 표현된 자원을 HTTP 메서드를 이용해 CRUD 연산을 할 수 있음. 따라서 REST는 자원을 명시해 연산을 수행하고 상태를 주고받는 것.
+ URI: 인터넷에 있는 자원을 나타내는 주소. 하위 개념으로 URL(인터넷에서 자원의 위치를 알 수 있는 규약), URN(자원의 위치 정보가 아닌 실제 자원을 특정)
- REST API: REST를 기반으로 한 인터페이스.
-> 작동 방식
(1) 클라이언트가 URL로 식별한 자원에 대해 HTTP 메서드를 사용해 REST API로 요청
(2) REST API가 HTTP 요청 메세지에 실려 서버에 전달됨
(3) 서버에서는 수신한 HTTP 요청 메세지를 바탕으로 요청 사항을 처리하고 HTTP 응답 반환 -> 성공 여부+정보
(4) 응답 메세지는 자원에 대한 정보를 JSON or XML 등의 형태로 포함. 클라이언트는 이 정보를 수신
'Cs' 카테고리의 다른 글
4. 자료구조 (0) | 2024.10.30 |
---|---|
3. 데이터베이스 (0) | 2024.10.29 |
1. 운영체제 (3) (0) | 2024.10.26 |
1. 운영체제(2) (0) | 2024.10.23 |
1. 운영체제(1) (0) | 2024.10.23 |