결국 CS 공부를 하는 이유는 우리가 만드는 서비스를 어떤 환경에서도 안전하고 빠르게 사용할 수 있도록 만들기 위해 꼭 알고 있어야 하는 배경지식이다. 그렇기 때문에 기술 그 자체를 이해하는 것도 중요하지만 성능 면에서 어떻게 영향을 주는지를 중점으로 보면 더 효율적으로 공부할 수 있을 것 같다.
Topic 5. HTTP1, HTTP2, 그리고 QUIC
(참고영상: 손너잘의 HTTP1, HTTP2, 그리고 QUIC)
성능하락의 가장 큰 요인은 대역폭과 레이턴시이고 아래처럼 단순하게 생각하기 쉽다.
그러나 2010에 한 구글 리포트에 따르면 대역폭은 상관이 없다고 발표한 바가 있다.
그래프를 보면 왼쪽의 대역폭 그래프는 처음 1m/bps에서 2m/bps로 증가시켰을 때는 로딩시간이 반 이상 줄어들었으나 그 이후로는 큰 차이가 없다. 하지만 레이턴시는 감소시킬때마다 그에 비례해서 로딩시간이 줄어드는 것을 볼 수 있다.
따라서 성능에는 레이턴시를 줄이는 것이 크게 영향을 미칠 수 있음을 의미한다.
HTTP는 TCP위에서 작동한다. 하지만 전송계층의 프로토콜에는 TCP 외에도 존재한다. 하지만 HTTP는 TCP로 인해 발전이 이루어 졌으며 발전 방향성에 크게 영향을 받았다.
TCP는 전송 제어 프로토콜이고 비신뢰성을 가진 IP 위에서 동작하므로 신뢰성을 확보하기 위해 여러 장치를 가지고 있다.
TCP 커넥션을 새로 만들어 사용하는 방식처럼 서버와 클라이언트가 한번만 쓰고 끊어버리는 것이 아니라 keep alive를 통해 계속 연결할 수 있다.
=> but 멍청한 프록시 문제 발생
HTTP 1.1에서는 기존 통신 방법과 달리 TCP 커넥션을 재활용할 수 있는 방법으로 3 Way Handshaking의 문제를 개선했다. 하지만 데이터를 동기적으로밖에 가져오지 못해 레이턴시로 이어졌다.
이에 대한 대안책이 파이프라인이다.
큐에 담긴 순서대로 FIFO 순서로 요청을 처리하도록 해준다. 하지만 Head of Line Blocking 문제, 즉 앞선에 요청한 작업이 끝나지 않으면 뒤의 모든 작업들이 처리되지 못하는 것 외에 여러 문제들이 발견되었다.
그래서 스트림을 도입해서 멀티플렉싱을 위해 여러 TCP 커넥션을 활용했던 HTTP 1.1과 달리 하나의 TCP 커넥션을 사용하지만 전송하는 데이터에 식별자를 추가해 각 데이터 응답을 구분하는 방법을 도입했다.
하지만 이 역시도 TCP 프로토콜 자체의 Head of Line Blocking과 같은 데이터 병목현상 문제로 인해 성능이 좋지 못했다고한다..
그래서 구글이 만든 것이 QUIC.
QUIC은 UDP를 사용하고 어플리케이션 계층에 신뢰성을 구현하려 했다.
데이터 스트림이 각자 다른 체인을 갖는다. 병목 현상이 생기더라도 전체 체인이 멈추지 않고 다른 체인에 영향을 주지 않는다.
Topic 6. OSI 7 Layer
ISO에서 발표한 국제 표준 네트워크 모델이다.
어플리케이션 계층(7계층) : 응용 프르세스를 직접 사용하여 직접적인 응요 서비스를 수행하는 계층 (ex. FTP, HTTP, SMTP, Telnet)
프레젠테이션 계층(6계층) : 데이터의 변환, 압축, 암호화가 이루어지는 계층
세션 계층 : 세션을 열고 닫는 메커니즘의 계층, 세션 복구
트랜스포트 계층 : 서로 다른 두 네트워크간의 전송을 담당하는 계층. 세그멘테이션(데이터를 세그멘트 단위로 나누는 것), 흐름제어, 요류제어 등 담당
- 세그멘테이션 작업이 있기 때문에 용량이 큰 비디오 등을 일부분부터 로드가 되었다면 볼 수 있고, 연결이 중간에 끊기더라도 큰 데이터가 날라가는 손실률을 줄일 수 있다.
- 흐름제어는 전송량 등을 조절하는 역할을 한다.
- 오류제어는 데이터에 손실이 없는지, 있다면 데이터를 다시 보내주게 처리한다.
네트워크 계층 : IP나 라우터 장비로 데이터 전송을 담당한다. 호스트의 IP 번호를 부여하고 도착지까지 최적의 경로를 찾아준다 (라우팅).
데이터링크 계층 : 동일한 네트워크 내에서의 전송을 담당한다. 오류제어, 흐름제어 제공한다. 트랜스포트 계층에서는 오류가 난 경우 다시 데이터를 보내주는데 반하여 해당 계층에서는 오류가 포함된 경우 데이터를 버리는 차이가 있다.
물리 계층 : 비트 단위들을 전기 신호로 변환해서 전송한다.
하지만 이 모델은 잘 설명하기 위한 모델이고 실제로 우리가 사용하는 모델은 TCP/IP 모델이다.
세션 계층과 트랜스포트 계층이 애플리케이션 계층에 통합되어 있다.
실제 데이터 전송 과정을 보면서 어떤 작업에서 각 계층이 사용되는지 보자!
상위 계층에서 하위 계층으로 데이터를 내려 받으면서 계층별 헤더를 붙이고 B로 보내고 해당 캡슐화된 데이터를 디캡슐레이트를 하면서 데이터를 얻는 과정입니다.
트랜스포트 계층에서는 먼저 TCP와 UDP 중 어느 것을 사용할지 정해야 하는데 (TCP는 신뢰기반- 데이터의 손실된 여부, 순서를 고려한다 / UDP는 보낸 후에는 책임X, 속도 빠르기 때문에 스트리밍 서비스에 많이 사용) 이 정보를 헤더에 넣어서 데이터에 붙여 캡슐화 한 것을 세그먼트라고 한다. 이를 네트워크 계층으로 보내고 출발/도착지에 대한 IP 정보를 헤더로 만들어 세그먼트에 붙인다. 그리고 캡슐화를 시키면 이것이 패킷이다. 이 패킷을 데이터링크 계층으로 보낸다. 출발지MAC주소와 가장 가까운 라우터의 MAC 주소를 헤더에 포함시킨다. (B의 MAC주소는 모르기 때문에) DHCP와 ARP를 통해 라우터의 IP를 바꿔 IP를 맥주소로 변환한 후에 라우터에 대한 도착지 MAC 주소를 만들어 헤더에 포함한다. (아래 그림 참고) 그리고 트레일러 정보도 붙는데 오류제어를 위한 정보이다. 이제 이를 캡슐화 시킨 것을 Frame이라 부른다. 마지막으로 이제 물리계층으로 보내고 여기서 전기신호로 바꿔 데이터를 전송하게 된다! 후
(참고영상: [10분 테코톡] 👍 파즈의 OSI 7 Layer)
Topic 7. 웹 접근성 & 표준
웹 표준은 왜 지켜야 하는 걸까?
웹표준은 어떠한 운영체제나 브라우저를 사용하여도 동일한 컨텐츠를 볼 수 있도록 웹에서 표준적으로 사용되는 기술이나 규칙입니다.
개발자 입장에서는 개발의 효율성을 (여러 브라우저마다 개발할 필요가 없다.) 기업은 서버 비용 우영 효율성 증대라는 장점이 있다.
그리고 검색엔진 최적화에도 유리하고 코드 자체가 가독성이 높아진다. (시맨틱 태그의 표준적 사용)
웹 접근성을 높인다?
장애인이나 노인분들 모두 개인의 능력에 상관없이 정보에 접근할 수 있도록 보장하는 것을 의미한다.
웹 표준은 웹 접근성 보조 도구가 웹을 좀 더 쉽게 이해할 수 있도록 해주기 때문에 접근성은 웹 표준을 지키는 것에서 부터 시작된다고 할 수 있다.
(참고영상: 미티의 웹 접근성 & 표준)
Topic 8. 웹 요청 & 응답과정
웹은 인터넷이 아니다?!
인터넷은
LAN(Local Area Network)같은 근거리 통신망, 구내 정보 통신망은 네트워크 매체를 이용하여 집, 사무실, 학교 등의 건물과 같은 가까운 지역을 한데 묶는 컴퓨터 네트워크이다. 이 외에도 MAN, WAN 등이 있다. 그 중에서도 범지구적으로 컴퓨터 네트워크들을 서로 연결해주는 네트워크가 인터넷이다. (Inter-Network : 컴퓨터 네트워크들의 네트워크)
웹은 이 인터넷 위에서 동작하는 서비스들 중 하나라고 볼 수 있다.
그러면 웹은 어떤 서비스일까?
('이'씨가 아닐까 하는 생각을 몇초정도 해본적 있는것 같은데..^^아니였던걸로..)
당시 빠르게 발전하고 있던 인터넷과 HyperText 같은 새로운 컴퓨터 기술들을 활용하여 이 문제를 해결하고자 했다.
(웹이 탄생한 제안 문서라고 함)
웹의 존재 이유는 정보의 공유이다. 웹은 수많은 요청과 응답 사이클의 연속으로 이루어져 있다.
HTTP(S)는 클라이언트와 서버간의 통신 규약인데 이 HTTP는 대표적인 특성이 있다.
비연결성 (Connectionless)
클라이언트의 요청에 대해 서버가 응답을 마치면 연결을 끊어버린다. 다음 요청은 새로 연결을 통해 이루어진다.
따라서 매번 모든 요청에 대해 새로운 연결/해제 과정을 거치므로 네트워크 비용 측면에서 비효율적이다. (Overhead)
보완책으로 HTTP/1.1 Keep-Alive 같은 경우 서버와 클라이언트 사이에서 통신이 없어도 지정된 시간동안 연결을 유지한다.
무상태 (Stateless)
서버와 크라이언트는 하나의 요청이 진행되는 동안만 서로를 인지한다. 클라이언트 인증(로그인)이 필요한 서비스에서 불편하기 때문에 쿠키, 세션, 토큰(OAuth, JWT)를 통해 상태를 기억하여 보완하고 있다.
HTTP Status Code (응답 코드, 상태 코드)
클라이언트의 요청에 대해서 서버는 요청에 대한 처리 상태를 숫자 코드로 반환한다.
1XX : (정보) 요청을 받았으며 프로세스를 계속한다.
2XX : (성공) 요청을 성공적으로 받았으며 인식해서 처리했다.
3XX : (리다이렉션) 요청 완료를 위해 추가 작업 조치가 필요하다.
4XX : (클라이언트 에러) 요청의 문법이 잘못되었거나 요청을 처리할 수 없다.
5XX : (서버 에러) 서버가 명백히 유효한 요청에 대해 충족을 실패했다.
HTTP Method
클라이언트가 요청을 보낼 때 해당 요청의 목적이 뭔지 명시한다.
웹 요청과 응답과정
1. URL
Uniform Resource Locator. 네트워크상 자원의 위치(주소)
URL 을 입력하고 엔터를 치면
2. HTTP Request
홈페이지에 대한 요청을 서버로 전송한다.
3. 서버가 요청 처리
Request Headers 확인 후 요청에 상응하는 로직을 수행하여 응답을 생성한다.
4. 서버가 클라이언트에 응답
5. 클라이언트가 응답을 받은 후 필요한 리소스 추가 요청 & 응답 받기
CSS, Javascript 등..
6. 클라이언트가 모든 리소스 요청에 대한 응답을 받음
렌더링 과정을 통해 리소스를 통합해 화면에 뿌려준다.
전체 과정 
(참고 영상: [10분 테코톡] 🎧 삭정의 Web 요청 & 응답과정)
