SEB_FE_45
Section 3. Unit 6. [네트워크] 심화
✅TCP/IP
1. 패킷교환 방식의 이점에 대해 이해한다.
- 패킷교환 방식 이전의 통신 방식은 회선교환 방식이다.
- 회선교환 방식은 1:1 연결만 가능했기 때문에 즉시성이 떨어지는 단점이 있었다.
- 이에 개발된 방식이 패킷교환 방식이다. 패킷은 pack와 buket이 합쳐진 단어로, 소포라는 의미이다.
- 즉, 데이터를 패킷 단위로 나누고, 패킷에 출발지와 목적지 정보를 담아 보내는 방식이다.
- 이 경우 특정 회선이 전용선으로 할당되지 않기 때문에 빠르고 효율적인 데이터 전송기 가능하다.
2. IP의 비연결성, 비순서성, 비신뢰성에 대해 이해한다.
- IP(Internet Protocol)
- 출발지에서 목적지까지 데이터가 전달되기 위한 규칙의 일환으로 컴퓨터에 IP주소를 부여하여 통신한다.
- IP주소에 패킷이라는 통신 단위로 데이터를 전달한다.
- 패킷 단위로 전송하면 노드들은 목적지 IP에 도달하기 위해 서로 데이터를 전달한다.
- 서버에서 무사히 데이터를 전송받으면, 서버도 이에 대한 응답을 패킷을 이용해 전달한다.
- IP의 한계
- 비연결성
- 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷을 전송한다.
- 클라이언트가 서버의 상태를 파악할 방법이 없다.
- 비신뢰성
- 중간에 패킷이 사라질 수 있다.
- 클라이언트가 패킷이 중간서버에서 사라진 사실을 파악할 방법이 없다.
- 비순서성
- 용량이 큰 데이터는 패킷단위로 잘라서 전달하는데, 전달 중 패킷들이 서로 다른 노드로 이동하는 경우, 클라이언트가 의도하지 않은 순서대로 데이터가 전달될 수 있다.
- 비연결성
3. TCP의 3 way handshake 및 그와 비교되는 UDP에 대해 이해한다.
TCP (전송 제어 프로토콜)은 두 개의 호스트를 연결하고 데이터 스트림을 교환하게 해주는 중요한 네트워크 프로토콜이다. TCP는 데이터와 패킷이 보내진 순서대로 전달하는 것을 보장해준다.
출처 : https://developer.mozilla.org/ko/docs/Glossary/TCP
위키백과 - 전송제어 프로토콜
전송 제어 프로토콜 - 위키백과, 우리 모두의 백과사전
위키백과, 우리 모두의 백과사전. 전송 제어 프로토콜(Transmission Control Protocol, TCP, 문화어: 전송조종규약)은 인터넷 프로토콜 스위트(IP)의 핵심 프로토콜 중 하나로, IP와 함께 TCP/IP라는 명칭으로
ko.wikipedia.org
- TCP의 특징
- 3 way handshake(가상연결)
- TCP는 장치들 사이에 논리적 접속을 성립하기 위해 3 way handshake를 사용하는 연결지향형 프로토콜이다.
- 연결 방식
- 클라이언트는 서버에 접속을 요청하는 SYN(Synchronization - 연결요청 플래그) 패킷을 보낸다.
- 서버는 SYN 요청을 받고, 클라이언트에게 요청을 수락한다는 ACK(Acknowledgement - 응답)와 SYN이 설정된 패킷을 발송한다.
- 클라이언트가 서버에게 ACK를 보내면 연결이 성립되어, 데이터를 전송할 수 있다.
- TCP는 데이터 전송이 성공적으로 이루어지면, 이에 대한 응답을 돌려주기 때문에 IP 패킷의 한계인 비연결성을 보완할 수 있다.
- 패킷이 순서대로 도착하지 않으면, TCP 세그먼트에 있는 정보를 토대로 다시 패킷 전송 요청할 수 있다. 이를 통해 IP 패킷의 한계인 비순서성을 보완할 수 있다.
- 3 way handshake(가상연결)
- UDP(User Datagram Protocol) 특징
TCP의 안정성을 필요로 하지 않는 애플리케이션의 경우 일반적으로 TCP 대신 비접속형 사용자 데이터그램 프로토콜(User Datagram Protocol)을 사용한다. 이것은 전달 확인 및 순차 보장 기능이 없는 대신 오버헤드가 작고 지연시간이 짧다는 장점이 있다.
출처 : 위키백과 - 전송제어 프로토콜
위키백과 - 사용자 데이터그램 프로토콜
사용자 데이터그램 프로토콜 - 위키백과, 우리 모두의 백과사전
위키백과, 우리 모두의 백과사전. UDP은 여기로 연결됩니다. 다른 뜻에 대해서는 UDP (동음이의) 문서를 참고하십시오. 사용자 데이터그램 프로토콜(User Datagram Protocol, UDP)은 인터넷 프로토콜 스위
ko.wikipedia.org
✅네트워크 계층 모델
1. 네트워크 통신을 계층별로 나눈 이유에 대해 이해한다.
- OSI 7계층 모델은 제조사 상관없이 공통으로 사용할 수 있는 네트워크 표준 규격을 정의한 것이다. 하드웨어 및 소프트웨어가 수행하는 기능에 따라 7개의 계층으로 구분한다.
- 물리계층(CDMA 등) > 데이터링크 계층(Ethernet 등) > 네트워크 계층(IP 등) > 전송 계층(TCP, UDP 등) > 세션 계층(SQL 등) > 표현 계층(GIF, JPEG 등) > 응용 계층(HTTP, DNS 등)
- TCP/IP 4계층 모델은 OSI 모델을 기반으로 실무적으로 이용할 수 있도록 현실에 맞춰 단순화된 모델이다. 현대의 인터넷 표준이다.
- 네트워크 인터페이스 계층(OSI 계층의 물리계층 + 데이터링크 계층) > 인터넷 계층(OSI 계층의 네트워크 계층) > 전송 계층(OSI 계층의 전송 계층) > 애플리케이션 계층(OSI 계층의 세션, 표현, 응용 계층)
2. 통신 과정에서 일어나는 데이터 캡슐화에 대해 이해한다.
- 데이터 송신자 기준 : 캡슐화(상위 계층에서 하위계층으로 데이터를 전달하면서, 각 계층에서 필요한 정보(헤더 - 데이터링크 계층에서는 트레일러)를 데이터에 추가한다.
- 데이터 수신자 기준 : 역캡슐화(하위 계층에서 상위계층으로 데이터를 전달하면서, 각 계층에서 헤더를 제거해 나간다.)
✅HTTP(응용계층의 대표적 프로토콜)
1. HTTP 메시지 구조를 이해한다.
- 클라이언트 서버 구조로 이루어져 있다(Request - Response 구조).
- 클라이언트는 서버에 요청을 보내고, 응답 대기 - 서버는 요청에 대한 결과를 만들어 응답
2. HTTP의 무상태성과 비연결성에 대해 이해한다.
- 무상태성(stateless) : 서버가 클라이언트의 상태를 보존하지 않음. 데이터 요청 시 필요한 데이터를 다 담아서 전송하기 때문에 아무 서버나 호출해도 된다.
- 장점 : 서버 확장성이 높다(스테일 아웃). 요청 서버에 장애가 발생하더라도 다른 서버에서 응답을 전달 할 수 있기 때문에 클라이언트는 다시 요청할 필요가 없다.
- 단점 : 클라이언트가 추가로 데이터를 전송해야 한다.
- 상태 유지(stateful) : 서버가 클라이언트의 상태를 기억함
- 단점 : 항상 같은 서버가 유지되어야 한다. 이에 해당 서버에 장애 발생 시 유지되던 상태 정보가 삭제되어 처음부터 다시 서버에 요청해야 한다.
- 무상태성의 한계
- 로그인이 필요없는 단순 서비스 소개화면은 무상태로 설계가 가능하다.
- 단, 로크인이 필요한 서비스의 경우에는 상태를 유지해야 하기 때문에 브라우저쿠키, 서버세션, 토큰 등을 이용해야 한다.
- 비연결성
- TCP/IP는 기본적으로 연결을 계속 유지한다. 이 경우, 연결을 유지하는 서버의 자원이 계속 소모된다.
- HTTP는 실제로 요청을 주고받을 때만 연결을 유지하고 응답을 주고나면, TCP/IP 연결을 끊는다. 이를 통해 최소한의 자원으로 서버 유지를 가능하게 한다.
- 트래픽이 많지 않고, 빠른 응답을 제공할 수 있는 경우, 비연결성의 특징은 효율적으로 작동한다.
- 단, 트래픽이 많고, 큰 규모의 서비스 운영 시 비연결성은 한계를 보인다.
- 비연결성의 한계
- TCP/IP 연결을 새로 맺어야 한다. = 3 way handshake 시간 추가
- 웹 브라우저로 사이트를 요청하면 HTML, CSS, JavaScript, 추가 이미지 등 수많은 자원이 함께 다운로드 된다.
- 위의 한계점은 HTTP 지속연결로 문제를 해결한다.
3. HTTP 헤더 중 바디를 설명하는 헤더인 표현헤더에 대해 이해한다.
- HTTP 헤더는 HTTP 전송에 필요한 모든 부가정보를 담기 위해 사용한다(ex. 메시지 바디의 내용, 크기, 압축, 인증 등)
- 표현헤더는 표현 데이터의 형식, 압축방식, 자연 언어, 길이 등을 설명하며, 요청과 응답 둘 다 사용한다.
4. HTTP 헤더 중 요청과 응답에서 주로 사용되는 헤더에 대해 이해한다.
- 요청(Request)에서 자주 사용되는 헤더
- From : 유저 에이전트의 이메일 정보 - 일반적으로 잘 사용하지 않으며, 주로 검색엔진에서 사용함
- Referer : 이전 웹 페이지 주소 - 현재 요청된 페이지의 이전 웹 페이지 주소이며, Referer을 사용하면 유입경로 수집 가능
- User-Agent : 유저 에이전트 애플리케이션 정보 - 통계정보, 어떤 종류의 브라우저에서 장애가 발생하는지 파악 가능
- Host : 요청한 호스트 정보(도메인) - 필수헤더, 하나의 서버가 여러 도메인을 처리해야 할 때, 하나의 IP 주소에 여러 도메인이 적용되어 있을 때, 호스트 정보를 명시하기 위해 사용
- Origin : 서버로 POST 요청을 보낼 때, 요청을 시작한 주소를 나타냄 - 요청 보낸 주소와 받는 주소가 다르면 CORS 에러 발생, 응답 헤더의 Access-Control-Allow-Origin과 관련
- Authorization : 인증 토큰을 서버로 보낼 때 사용하는 헤더 - "토큰의 종류 + 실제 토큰 문자"를 전송
- 응답(Response)에서 사용되는 헤더
- Server : 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보
- Data : 메시지가 발생한 날짜와 시간
- Location : 페이지 리디렉션
- 웹브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, 해당 위치로 리다이렉트(자동이동)
- 201(created) : Location 값은 요청에 의해 생성된 리소스 URI이다.
- 3xx(Redirection) : Location 값은 요청을 자동으로 리디렉션하기 위한 대상 리소스를 가리킨다.
- Allow : 허용 가능한 HTTP 메서드 - 405(Method Not Allowed)에서 응답에 포함된다.
- Retry-After : 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간 - 503(Service Unavailable) 응답에서 서비스가 언제까지 불능인지 알려줄 수 있다.
5. HTTP 헤더 중서버에 요청하는 콘텐츠를 협상할 수 있는 협상헤더에 대해 이해한다.
- Accept-Language 헤더를 통해 서버에 요청하기
- 한국어 브라우저에서 특정 웹사이트에 접속했을 때, 콘텐츠 협상이 적용되지 않으면, 서버는 요청으로 받은 우선순위가 없으므로, 기본 언어인 영어로 응답한다.
- 클라이언트에서 Accept-Language로 KO를 작성해 요청하면 한국어로 된 응답을 돌려준다.
- 한국어를 지원하지 않는 서버라면? 우선순위를 정해서 요청한다.
- 우선순위는 Quality Values(q) 값을 사용하며, q 값은 0~1 중 1에 가까울 수록 우선순위가 높다(생략하면 1).
- Accept-Langage: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7로 요청하면 우선순위는 아래와 같다.
- 1순위 : ko-KR;q=1(q생략)
- 2순위 : ko;q=0.9
- 3순위 : en-US;q=0.8
- 4순위 : en;q=0.7
- 한국어 지원이 안되는 경우, 다른 언어보다 영어를 클라이언트가 선호하기 때문에 영어로 응답을 주게 된다.
✅HTTPS(HTTP Secure)
1. 왜 HTTPS가 HTTP보다 안전한 지 이해한다.
- HTTP 프로토콜을 더 안전하게 사용할 수 있음을 의미한다.
- HTTP와 달리 요청과 응답으로 오가는 내용을 암호화 한다.
2. HTTPS의 암호화 방식에 대해 이해한다.
- 데이터를 암호화 할 때에는 암호화할 때 사용할 키와 암호화 한 것을 해석(복호화)할 때 사용할 키가 필요하다.
- 암호화와 복호화를 동일한 키로 한다면 대칭 키 암호화 방식이라고 한다.
- 암호화와 복호화를 서로 다른 2개의 키로한다면, 공개 키(비대칭 키) 암호화 방식이라고 한다.
3. HTTPS에서 사용하는 대칭키, 비대칭키 방식에 대해 이해한다.
- 대칭 키 암호화 방식(키가 1개)
- 암호화 키와 복호화 키 동일하다.
- 공개 키 방식에 비해 연산 속도가 빠르다.
- 단, 키를 주고받는 과정에서 탈취당하면 암호화가 소용 없어지기 때문에 키를 관리하는데 신경을 많이 써야 한다.
- 공개 키(비대칭 키) 암호화 방식(키가 2개)
- 암호화 키와 복호화 키가 다르다(공개 키와 비밀 키).
- 공개키는 누구나 접근이 가능하다.
- 요청을 보내는 사용자가 공개 키를 갖고, 요청을 받는 서버가 비밀 키를 갖는다.
- 비밀 키는 서버가 해킹 당하는 게 아닌 이상 탈취되지 않는다.
- 대칭 키 방식보다 보안성이 더 좋다.
- 단, 복잡한 연산이 필요하여 더 많은 시간을 소모한다.
4. 직접 로컬에서 HTTPS 인증서를 발급할 수 있다.
- SSL/TLS 프로토콜
- CA를 통한 인증서 사용
- 대칭 키, 공개 키 암호화 방식을 모두 사용
- 인증서와 CA(Certificate Authority)
- HTTPS 사용 하면 브라우저가 서버의 응답과 함께 전달된 인증서를 확인할 수 있다.
- 인증서 : 신원 보증
- CA : 인증서를 발급해주는 공인된 기관
- 인증서 발급 과정
- 서버 ➡️ 인증서 발급을 위해 CA로 서버의 정보와 공개키를 전달한다.
- CA ➡️서버의 공개 키와 정보를 CA의 비밀키로 암호화하여 인증서를 발급한다.
- 서버 ➡️ 클라이언트에게 요청을 받으면 CA에게 발급받은 인증서를 보내준다.
- 클라이언트가 사용하는 브라우저에는 CA들의 리스트와 공개 키를 내장하고 있다.
- 해당 인증서가 리스트에 있는 CA가 발급한 인증서인지 확인하고, 리스트에 있는 CA라면 해당하는 CA의 공개 키를 사용해서 인증서의 복호화를 시도한다.
- 복호화 성공 ➡️ 클라이언트 서버의 정보와 공개키를 얻게 됨과 동시에 해당 서버가 신뢰할 수 있는 서버임을 알 수 있다.
- 복호화 실패 ➡️ 서버가 보내준 인증서가 신뢰할 수 없는 인증서임을 확인하게 된다.
- 대칭 키 전달
- 복호화를 통해 획득한 서버의 공개 키는 클라이언트와 서버가 함께 사용하게 될 대칭키를 주고받을 때 쓰게 된다.
- 클라이언트 ➡️ 서버에 대칭키를 보낼 때 서버의 공개키를 이용해서 보내면 탈취의 위험성이 줄어들고, 대칭키를 사용함에 따라 효율성이 증가한다.
- 클라이언트와 서버는 HTTPS 요청을 주고 받을 때 대칭키를 사용해서 데이터를 암호화하여 전달하게 된다.
- 정리 : 서버와 클라이언트 간의 CA를 통해 서버를 인증하는 과정과 데이터를 암호화하는 과정을 아우른 프로토콜을 SSL 또는 TLS라고 말하고, HTTP에 SSL/TLS 프로토콜을 더한 것을 HTTPS라고 한다.
회고
음.. HTTP Headers까지는 그런데로 이해가 됐는데... HTTPS는 집중력이 떨어졌는지 여러번 읽어도 눈에 들어오지가 않는다. 내일 한번 더 읽어보고 이해가 안되면.. 강의를 찾아서 들어봐야겠다.
간단하게 HTTP에 인증서 관련 프로토콜을 더해 안정성을 확보한 것이 HTTPS 라는 것은 알겠는데.. 암호화, 복호화 이런 단어가 눈에 익지 않아서 내용에 집중이 안되는 것 같다.
내가 해온 길을 돌아보기보다는 앞으로 내가 성장할 것을 기대하며 앞을 보는 내가 되야겠다!
얘아 후회하는 삶을 살지 않을 순 없지만 그 순간마다 시간이 너를 앞지르고 있다는 것을 잊지 말고 살아가렴.
뒤돌아보지 말고 매 순간 앞에 놓여있는 시간을 바라보고 살도록 노력해라. 그래야 조금이라도 시간에 얽매이지 않고 살아간다.
시간이 빠르다는 것은 그것이 정말로 빠르게 가는 것이 아니라 내가 자꾸 뒤를 돌아보는 것이란다. 어떤 소중한 것을 놔두고 왔기에 그렇게나 돌아보는 것이란다.
정영욱 - 참 애썼다 그것으로 되었다 中
'SEB_FE_45(코드스테이츠) > section 3.' 카테고리의 다른 글
| Unit 5] [사용자 친화 웹] 웹 표준 & 접근성 (0) | 2023.06.28 |
|---|---|
| Unit 3] [React] Custom Component(CDD, 개발도구) (0) | 2023.06.16 |
| Unit 2] [사용자 친화 웹] UI/UX part.3 - Figma 클론 과제 (0) | 2023.06.15 |
| Unit 2] [사용자 친화 웹] UI/UX part.3 - Figma (0) | 2023.06.14 |
| Unit 2] [사용자 친화 웹] UI/UX part.2 (1) | 2023.06.13 |