네트워크
OSI 7 계층
-
OSI 7 계층을 나누는 이유? 표준화! 하나의 표준 규격을 규정화하여 서로 다른 회사의 기계들 간 통신이 원활하게 이루어질 수 있도록, 업체 및 개발자가 만드는 디지털 통신 제품과 소프트웨어 프로그램이 상호 연동될 수 있도록 안내하고, 통신 도구 간의 명확한 비교를 용이하게
-
7계충 응용계층
- 실제로 사용자와 직접적으로 상호작용하는 계층
- HTTP, FTP, DNS
-
6계층 표현계층
- 응용프로그램이나 네트워크를 위해 데이터를 표현하는 것
- 데이터를 안전하게 전송하기 위해 암호화, 복호화, 파일 인코딩
- JPEG
-
5계층 세션계층
- 서로 다른 기기, 컴퓨터, 서버 간 대화가 필요하면 세션을 만들어야 하는데, 이 작업이 여기에서 처리된다.
- 데이터가 통신하기 위한 논리적인 연결을 담당하며
- TCP/IP 세션을 만들고 없애는 책임을 가진다
- API, Socket
-
4계층 전송 계층
- 데이터의 전송을 조율한다.
- 보낼 데이터의 용량, 속도, 목적지 등을 처리
- 목적지에 신뢰할 수 있는 데이터를 전달하도록 한다.
- TCP : 신뢰성, 연결 지향적
- UDP : 비신뢰성, 비연결성, 실시간
-
3계층 네트워크계층
- 여러 라우터를 통한 라우팅을 비롯한 패킷 전달을 담당
- 라우팅, 흐름 제어, 오류 제어, 세그먼테이션 등을 수행한다
- IP 프로토콜로 캡슐화 → IP 패킷
- 라우터, IP
-
2계층 데이터링크계층
- 직접 연결된 노드 사이의 데이터 전송을 제공하고, 물리 계층의 오류 수정도 처리한다.
- 이더넷 헤더와 트레일러가 추가된 데이터 → 프레임
- 데이터에 MAC 주소를 부여하고 에러검출, 재전송, 흐름 제어를 진행한다
- 브릿지, 스위치
-
1계층 물리계층 :
- 시스템의 전기적, 물리적 표현
- 주로 전기적, 기계적인 특성을 이용하여 통신 케이블로 데이터를 전송하는 역할을 한다. (리피터, 케이블, 허브)
TCP
- Transmission control protocol
- 신뢰성 있는 데이터 전송을 지원하는 연결 지향형 프로토콜
- 3-way handshake를 통해 연결을 설정하여 통신을 시작하고
- 4-way handshake를 통해 연결을 해제한다.
- 흐름제어, 혼잡제어, 오류제어를 통해 신뢰성을 보장하는 대신 UDP에 비하여 속도가 느리다
- 데이터의 전송 순서를 보장하며 수신 여부를 확인할 수 있다.
- 대부분의 HTTP통신, 이메일, 파일 전송
- 패킷 인터넷 내에서 라우팅을 효율적으로 하기 위하여 데이터를 여러 조각으로 나누어 전송하는데, 이때의 조각을 패킷이라고 한다.
흐름제어
- 송신측과 수신측 사이의 데이터 처리 속도 차이를 해결하기 위한 기법
- 받는 쪽에서 처리되는 양보다 보내는 양이 더 많으면 수신측의 큐를 넘어서 데이터가 손실될 수 있다.
- Stop and Wait
- 매번 전송한 패킷에 대한 확인 응답을 받은 후 그 다음 패킷을 전송
- 비효율적
- 슬라이딩 윈도우
- 수신측의 buffer크기만큼만 송신측에서 확인 응답 없이 세그먼트를 전송
- ACK 프레임을 수신하지 않더라도 여러 개의 프레임을 연속적으로 전송 가능하다
오류제어
- 오류 검출과 재전송을 포함
- ARQ(Automatic Repeat Request) 기법을 사용, 프레임에 오류가 생기면 재전송
- Stop and Wait ARQ
- 송신측에서 1개의 프레임을 받을 때마다 에러 유무에 따라
ACK또는NAK을 보냄 NAK을 받거나, 타임 아웃이 되면 송신 측은 데이터를 재전송
- Go-Back-n ARQ (슬라이딩 윈도우)
- 확인된 마지막 프레임 이후로 모든 프레임을 재전송, 폐기
- 전송 측은 전송된 모든 프레임의 복사본을 가지고 있어야 한다.
- NAK은 손상된 프레임 자체 번호를 반환한다. 수신 측은 이후의 데이터를 폐기하고, 송신측은 손상된 데이터 이후의 모든 데이터를 재전송한다. 타임아웃도 마찬가지. 마지막 ACK된 데이터 이후부터 재전송한다.
- SR(Selective-Reject) ARQ
- 손상되거나 손실된 프레임만 재전송한다.
- 프레임 재배열 등의 추가 로직이 필요하다.
- 폐기 방식을 사용하지 않으므로 재배열을 위한 버퍼도 추가로 필요하다.
→ 비용 및 유지 관리 비용 증가
혼잡 제어
- 네트워크 혼잡을 피하기 위해 송신 측에서 데이터 전송 속도를 제어하는 것
- 흐름 제어는 송신측과 수신측의 전송 속도를 다루는 데 반해, 흐름제어는 라우터를 포함, 보다 넓은 관점에서의 전송 문제를 다루게 된다.
- AIMD
- Additive Increase, Mutlcative Decrease
- 합 증가 곱 감소 알고리즘
- 전송한 패킷이 문제 없이 도착한다면 window size를 1씩 증가시키고, 패킷 전송에 실패하면 window size를 절반으로 감소
- 네트워크가 혼잡해지는 상황을 미리 감지하지 못하고, 초기 네트워크의 높은 대역폭을 사용하지 못한다.
- Slow Start
-
AIMD는 처음에 전송 속도를 올리는데 시간이 오래 걸렸음
-
Slow start는 패킷이 문제 없이 도착하면 각각의 ACK 패킷마다의 window size를 1씩 늘림. 즉 한 주기가 지나면 window size는 두배!
-
혼잡 현상이 발생하면 혼잡 회피 알고리즘을 이용한다.
- 혼잡 회피: 윈도우 크기가 임계값에 도달한 이후에는 데이터 손실 발생 확률이 높아지므로 윈도우 크기를 선형적으로 1씩 증가, 혼잡 현상이 발생하면 윈도우 크기는 1로 감소시키고 임계값은 패킨 손실 시의 윈도우 크기 절반으로
- 빠른 재전송
- 혼잡 회피의 변형
- 원래는 일정 시간 내에 해당 패킷의 ACK가 오지 않으면 재전송(timeout)
- 빠른 재전송에서는 이러한 time out을 기다리는 대신 sender가 중복된 순번의 패킷을 3개 받으면 재전송
- 빠른 회복
- window size를 1로 떨어뜨리는 대신 반으로 줄인 후 1씩 선형 증가시키는 전략을 사용
UDP
- User Datagram Protocol
- 데이터를 데이터그램(독립적인 관계를 지니는 패킷) 단위로 처리한다
- 비연결형 프로토콜로 사전 연결 없이 데이터를 전달한다.
- 하나의 메시지에서 분할된 각각의 패킷은 다른 경로로 재전송되고, 이러한 패킷에 순서를 부여하거나 재조립하지 않는다.
- 손상된 세그먼트에 대한 재전송을 하지 않는다.
- 속도가 굉장히 빠르고, 네트워크 부하가 적지만, 신뢰성있는 데이터 전송을 보장하지는 못한다.
- Real Time Protocol(전화), Multicast(1: N), 동영상
3-way handshake
- 클라이언트는 서버에 접속을 요청하는 SYN(a) 패킷을 보낸다
- 서버는 클라이언트의 SYN(a) 패킷의 요청 수락인 ACK(a+1) 패킷과 역시 포트를 열어달라는 SYN(b) 패킷을 보낸다.
- 클라이언트는 두 패킷을 받고 이에 대한 응답으로 ACK(b+1) 패킷을 보내며 연결이 성립된다.
- 왜 2way가 아니라 3way?
TCP는 양방향성 연결이기 때문에 클라이언트와 서버가 서로 존재를 알리고 패킷을 보낼 수 있다는 신호를 보내야 하기 때문
4-way handshake
- 클라이언트는 서버에게 연결을 종료하겠다는 FIN 패킷을 보내고
- 서버는 클라이언트 요청에 대한 응답으로 ACK 패킷을 보내고, 처리해야 할 통신이 끝날때까지 기다린다.
- 서버가 처리해야할 통신이 끝나면 서버 역시 연결을 종료하겠다는 FIN 패킷을 전송한다.
- 클라이언트는 FIN 패킷에 대한 확인 응답으로 ACK 패킷을 보낸다.
- 클라이언트의 ACK 패킷을 받은 서버는 소켓 연결을 닫고
- 클라이언트는 서버로부터 아직 받지 않은 데이터를 대비하여 기다리는 과정을 거친다.
대칭키와 공개키
대칭키 암호화
- 암호화에 사용되는 키와 복호화에 사용되는 키가 동일한 암호화 기법이다.
- 사용자가 모두 키를 가지고 있어야 한다.
- 키 전달 및 관리에 어려움이 있지만, 연산 속도가 빠르다.
공개키
- 암호화에 사용하는 키와 복호화에 사용하는 키가 다르다. → 비대칭키 암호화라고 부르기도
- public key로 암호화하는 경우 : data의 보안에 중점을 둔다.
- private key로 암호화하는 경우 : 인증 과정에 중점을 둔다. 공개키로 복호화가 가능하니 data 보안에는 안좋을텐데? → 데이터의 보안보다는 data 제공자의 신원 보장이 목적. data가 복호화된다면 data 제공자가 private key를 가지고 있는 사람이라는 걸 보장한다.
- 대칭키의 키 전달 문제는 해결, but 복잡한 연산을 수행하기 때문에 느리고 복잡하다.
- 키 길이가 길고
- 중간에 인증과정이 없으므로 중간자 공격에 취약하다(전자서명, 인증서 이용)
보통 둘을 혼용, 용량이 큰 정보는 대칭키로, 암호화하고 암호화에 사용된 대칭키를 공개키로 암호화하여 전달하는 하이브리드 방식이 일반적으로 이용된다
HTTP, HTTPS
HTTP
웹 서버와 클라이언트 간의 문서를 교환하기 위한 통신 규약
-
TCP/IP 기반
-
비연결 지향
- 요청에 대한 응답의 데이터를 전송한 후 연결을 종료한다.
- 각 요청에 대한 사용자 정보가 필요하다. (쿠키, 세션)
- 연결을 유지하기 않기 때문에 리소스 낭비가 줄어든다.
-
단방향성
- 클라이언트의 요청에 대한 응답이기 때문에 서버가 먼저 응답하지 않는다.
-
문제점
- 평문(암호화하지 않은) 통신이기 때문에 도청이 가능하다.
- 통신 상대를 확인하지 않기 때문에 위장이 가능하다.
- 완전성을 증명할 수 없기 때문에 변조가 가능하다.
HTTPS
HTTP의 문제점을 해결하기 위한 방법
- SSL(Secure Socket Layer)라는 프로토콜을 추가한다.
- HTTP는 TCP와 직접 통신했지만, HTTPS에서는 HTTP와 SSL이 통신하고, SSL은 TCP와 통신한다.
- 대칭키 암호화 방식과 공개키 암호화 방식을 모두 사용한다.
- CPU나 메모리 등 리소스가 많이 필요해서 서버 한대당 처리 가능한 Request수가 줄어든다.
SSL
CA(Certificate Authority) - 서드파티
서버-CA
- 서버를 운영하는 기업은 공개키와 사이트 정보를 보내 CA에 인증서를 요청한다.
- CA는 개인키로 암호화하여 인증서를 제공한다.
HTTP cookies
HTTP의 stateless(상태 정보를 유지하지 않음)로부터 파생되는 문제점을 해결하는 방법
- 유저가 웹사이트에 접속할 때 웹 서버가 생성하는 data
Uses
- Session Management: ex login - 유저가 로그인 페이지에 접속하면 unique session identifier가 포함된 쿠키를 보내주고, 로그인에 성공하면 해당 indentifier에 권한을 부여한다. 서버가 알아야 할 정보들을 저장한다.
- Save User Information : 옵션을 부여할 수 있다. 예를 들어 웹페이지 테마, 한 페이지에 몇 개의 정보를 보여줄 지
- Tracking : 요청의 URL, date/time, 지속시간 등을 저장함으로써 유저의 habit을 알아낼 수 있다.
session cookie
expiration date를 갖지 않은 것. memory에 저장되고, disk에는 저장 노노.
유저가 브라우저를 닫자마자 삭제된다. object형식
서버측에서 관리. 보안은 좋지만 서버 메모리를 많이 사용하게 된다.
클라이언트가 Request를 보내면 해당 서버 엔진이 클라이언트에 유일한 ID를 부여한다. 클라이언트는 세션 ID를 저장하고, 서버에 전달한다.
permanent cookie
expiration date를 갖는 쿠키. 이 기간이 끝나면 쿠키가 삭제된다.
하나의 domain당 제한이 있음. text형식.
클라이언트 로컬에 저장, 사용자가 따로 요청하지 않아도 브라우저가 자동으로 서버에 전송
Alternatives
- JSON Web Token(JWT) : user identity와 인증 정보를 저장한다. cookie는 자동으로 모든 HTTP request와 함께 전송되지만, JWT는 매번 직접 추가해줘야함
- HTTP authentication : 비밀번호를 Header에 넣어서 권한을 부여받는 방법.
- URL(Query String) : PHP session에서 쓰는 방식. unique session identifier를 query string에 추가. SSL이 적용돼있어야함.
REST와 RESTful
Representational State Transfer
서버의 자원을 정의하고, 자원에 대한 주소를 지정하는 방법 - HTTP URI(Uniform Resource Identifier_를 통해 resource를 명시하고, HTTP Method를 통해 해당 자원의 CRUD(Create, Read, Update, delete) Operation을 적용하는 것
+GET 은 Request body 에 내용을 넣지 않는다.
장점? 서버와 클라이언트의 역할을 명확하게 분리
단점? Method 가 제한적, 구형 브라우저는 PUT, DELETE 등을 지원해주지 못함
RESTful
REST 아키텍쳐 제약 조건을 준수하는 프로그래밍 인터페이스
Blocking I/O & Non-Blocking I/O
-
I/O 작업은 kernal level에서만 가능하기 때문에 user process와 스레드는 커널에게 요청한 후 작업이 끝날때까지 기다리는 시간을 가져야 한다.
-
Blocking I/O
가장 기본적인 모델- I/O 작업이 진행되는 동안 유저 프로세스는 자신의 작업을 중단한 채 기다리게 된다. 기다리는 동안 다른 작업을 수행하지 못하므로 자원이 낭비된다.
-
Non-Blocking I/O
- I/O 작업이 진행되는 동안 다른 processing을 허용한다.
- polling을 통해 작업이 끝났는 지 확인할 수도 있고
- DMA나 interrupts를 이용할 수도 있다.
로드밸런싱
여러개의 자원에 task들을 나누어 할당하는 것.
서버가 과부하됐을 때의 대응방안으로 하드웨어 성능을 올리거나(Scale-up), 여러 대의 서버가 나눠서 일하도록 만드는 것(Scale-out)이 있다.
- 하드웨어 향상 비용이 비싸며, 서버가 여러대 존재하면 무중단 서비스를 제공하는 환경 구성에 용이하므로 scale-out을 많이 이용한다.
- 이 때, 여러 서버에게 균등하게 트래픽을 분산시켜주는 것이 바로 로드 밸런싱
- static load distribution
- Round-Robin: 걍 하나씩 차례대로 할당하는 것
- Randomized static : 랜덤으로 배정. 미리 랜덤하게 순서를 정해놓으면 communication cost도 줄일 수 있다.
- work stealing(dynamic) : 일단 랜덤하게 배정하고, inactive한 processor가 이를 뺏어올 수 있게 한다.
주소창에 naver.com 을 치면 일어나는 일
- 사용자가 브라우저에 domain name(naver.com)을 입력
- 사용자가 요청한 URL에서 domain name 부분을 DNS 서버에서 검색한다. DNS 서버는 이를 IP 주소로 변환하여 (URL 정보와 함께)전달한다.
- 페이지 URL 정보와 전달받은 IP 주소를 이용하여 HTTP 요청 메시지를 생성하고, 이렇게 생성된 HTTP 메시지는 TCP protocol을 통해 해당 IP 주소의 컴퓨터로 전송된다.
- 도착한 HTTP 요청 메시지는 HTTP protocol을 통해 웹 페이지 URL 정보로 변환되고, 응답으로 데이터를 전달한다.
- 이러한 데이터는 다시 HTTP protocol을 통해 HTTP 응답 메시지가 되고, TCP 프로토콜을 통해 사용자의 컴퓨터로 전송된다.
- 웹 브라우저는 이를 웹 페이지 데이터로 변환하여 사용자가 볼 수 있게 한다.
IP 주소
- 어떤 네트워크의 어떤 컴퓨터인지를 구분하기 위한 식별 번호
→ 이러한 주소를 사람들이 접근하기 용이하도록 문자로 표현한 것이 Domain Name이다. - Domain name을 IP 주소로 변환해주는 시스템(서비스)을 DNS 서버라고 이야기한다.
