<이기곤, 학교에서 알려주지 않는 17가지 실무 개발 기술_문자열 인코딩부터 웹 필수 지식까지, 한빛미디어>

13장 데이터 압축(zlib)

p. 217

• 웹 또는 서버 간 주고받는 메시지를 압축하는 경우, TCP(or HTTP)*에서 무결성 검증을 하기 때문에 별도로 데이터 무결성을 확인할 필요는 없습니다. 하지만 TCP보다 더 낮은 수준에서 데이터를 주고받거나, UDP처럼 무결성을 보장하지 않거나 데이터 일부가 훼손될 수 있는 환경에서는 CRC32 값으로 데이터의 무결성을 확인하는 것이 좋습니다.

TCP?

구글링 수준으로 찾다가 이 부분은 조금 더 심층적인 학습이 필요한 것 같아 반복적으로 언급되는 OSI 7계층을 조금 더 공부한 뒤 정리하는 것으로 하겠다.

p.218

• 수많은 메시지를 동시에 처리하는 서버의 경우 작은 부하들이 쌓여 큰 부하가 될 수 있습니다. 서버 하나가 받을 수 있는 최대 메시지 개수를 정해두고, 그 범위 내에서 부하를 견딜 수 있는지 확인해야 합니다.

14장 HTTP

p. 229

• HTTP는 각 요청이 소켓* 1개를 점유하기 때문에 큰 문제가 생기지 않지만, TCP는 모든 요청이 소켓 1개를 사용하기 때문에 모든 요청이 1개의 소켓 안에서 섞이게 됩니다. 그래서 별도로 요청 ID와 같은 식별자를 사용하지 않으면 각 요청에 해당하는 응답을 구분할 수 없습니다. 또한, 프로토콜에서 응답이 왔는지 확인할 방법을 제공하지 않기 때문에 타임아웃 기능도 직접 구현해야 합니다.

• 정리하면, TCP는 HTTP보다 상대적으로 빠르지만 개발자가 연결 상태를 직접 관리해야 해서 로직이 복잡할 수밖에 없습니다. HTTP는 로직이 간단하지만 TCP보다는 느립니다.

소켓?

TCP에서 말했던대로 이 부분도 조금 더 공부를 한 뒤 정리하는 것으로 하겠다.

간단한 HTTP 서버 만들기

from flask import Flask
app = Flask(__name__)

@app.route('/')
def hello_world():
	return 'Hello, World!'
    
app.run()

간단한 서버라서 간단한 건가!
지난 시간동안 엘리스에서 Node.js로 서버를 만드는 것에 있어서는 환경 설정이 복잡하고 구조도 많았는데, Python에서는 이게 끝이라니, 편리했다.

그래서 궁금증이 든 점.
Python과 Node.js 서버 만드는 것의 차이는?
구글링한 결과로 정리해봤을 때,
Python으로 웹 개발을 하는 경우 데이터 분석이나 머신 러닝 쪽의 확장이 용이하고, Node.js의 강점은 JavaScript를 쓰는 것이다.
웹 개발에 집중돼 있는 것이 Node.js의 장점이자 단점.

참고 링크

덧붙여서 엘리스에서 Node.js를 백엔드에 공부하는 이유에 대해 운영진의 답변을 받았다.
1. 웹 프로그래밍 학습 과정에 일관성이 생기기 때문
2. API 제작을 배울 때 Node(Express)+MongoDB가 학습 효율이 높기 때문

내게 있어 첫 웹 개발 때 백엔드로 접한 프레임워크가 Flask이고, 이후Node.js 강의를 잠시 수강해본 적이 있는데, 확실히 첫 경험 때 아무것도 모르고 마냥 재밌게 썼던 Flask에 호감이 가고, 마냥 어렵기만 했던 Node.js 강의를 듣고는 '앞으로는 python만 써야지, pyhon 최고!'라고 생각했었다.

그런데 교육자 입장에서 보기에는 위의 이유로 인해 Node.js를 선택했다니, 인상깊었다. 지금 막 6주차가 끝났는데, 복습을 하면서 전체 커리큘럼을 되짚어 보면서 맥락을 파악해야겠다.

HTTP 2.0

p.235
웹 페이지 하나를 보기 위해 수십 번을 요청애야 하는 문제를 해결하조가, 한 번의 요청에 수십 개의 응답을 병렬로 보낼 수 있도록 개선하고 불필요한 오버헤드를 제거한 것이 바로 2.0 버전입니다. 그러나 2.0 버전에추가된 기능들을 모두 다루기엔 너무 광범위하므로 이 책에서는 다루지 않겠습니다.

에러 코드 종류

	메시지	의미
200	OK	요청이 성공했을 때
201	Created	리소스를 성공적으로 생성했을 때
301	Move Permanently	주소 이전. 클라리언트는 301 응답을 받는 즉시 새 주소로 이동함. 즉 서버 이동이라 불리며 새 주소는 location 헤더 값
400	Bad Request	올바르지 않은 요청을 보냈을 때
401	Unauthorized	접근 권한이 없을 때(접근하기 위해 인증이 필요하다는 뜻과 같음)
404	Not Found	서버가 제공하지 않는 주소나 존재하지 않는 주소로 요청을 보낼 때
405	Method Not Allowed	입력한 메서드를 허용하지 않을 때
500	Internal Server Error	모두 웹 서버 내부 또는 웹 서버를 구성하는 다른 내부 서버에서 에러가 발생할 때(클라이언트가 할 수 있는 게 없음)
502	Bad Gateway	``
503	Service Unavailable	``
504	Gateway Timeout	``

NAT 환경?

p. 245
요청 헤더의 Host 값을 사용하면 (신구 클라이언트)구분이 가능하지만 완벽하진 않습니다. IP와 포트 주소만으로는 NAT 환경, 클라이언트의 포트 재사용과 같은 상황을 구분할 수 없기 때문입니다.

구글링 만으로는 궁금증을 충족할 수 없는 부분이 많다... 아무래도 전문 서적을 찾아보거나 정보처리기사 공부를 부가적으로 해야할 것 같다.

쿠키값을 안전하게 다루는 방법

p. 248
쿠키는 악의적인 해커들이 자주 공격하는 곳입니다. 쿠키를 이용한 대표적인 공격 방법은 세션 가로채기, XSS나 CSRF와 같은 스크립트 삽입 등이 있습니다. 이러한 해킹 공격을 방지하려면 쿠키를 보호할 수 있는 HTTPS를 필수적으로 사용해야 하고, HTTP로 접속해도 HTTPS로 접속하게 서버 이동 처리하는 게 좋습니다.

p. 249
쿠키 설정 시 'Secure' 옵션을 추가하면 HTTPS로 통신할 때만 쿠키를 서버로 전송합니다. 추가로 'HttpOnly' 옵션을 추가하면 웹 브라우저에서 자바스크립트(document.cookie)를 통해 쿠키에 접근하는 것을 방지할 수 있습니다. 두 옵션을 추가하면 제삼자가 쿠키를 보거나 변조하는 상황을 방지할 수 있습니다.

CORS

p.252
CORS가 XSS와 같은 악성 자바스크립트 실행 공격을 막을 수 있는 건 아닙니다. 물론 CORS가 사전에 지정하지 않은 도메인으로의 호출을 막는 건 사실입니다. 그러나 이 방어 정책은 브라우저에 해당되므로 해킹된 웹 서버에서 악성 자바스크립트가 실행되거나 민감한 데이터가 유출되는 것을 막을 수는 없습니다.

15장 RESTful API

http://doc.microsoft.cm/ko-kr/azure/architecture/best-practices/api-design

p. 258
RESTful API는 서버와 클라이언트가 메시지를 주고받을 때 가장 많이 사용하는 통신 규격입니다. REST란 representational state transfer의 약자로 분산 시스템을 위한 소프트웨어 아키텍처의 한 형태를 가리키며, RESTful이란 REST의 조건을 만족한다는 뜻입니다.

p. 81
크롤러는 쉽게 성능 저하(병목) 현상이 생길 수 있습니다. 정규 표현식은 언어나 플랫폼과 상관없이 동작하지만, 대체로 정규 표현식의 처리 속도는 꽤 느린 편입니다. 그리고 검사해야 하는 패턴이 길면 길수록 더 느려집니다.
예를 들면 웹 페이지 요청 또는 RESTful API처럼 제한된 시간 내에 응답을 보내야 하는 경우를 생각해볼 수 있습니다. 만약 요청 메시지(HTML 또는 JSON)에 담긴 긴 문자열을 정규 표현식으로 검사한다면, 웹 서버의 처리 속도가 전체적으로 크게 떨어질 수 있습니다. 이런 경우에는 정규 표현식 대신 개발 환경에서 사용할 수 있는 파서 라이브러리를 사용하는 게 좋습니다.

분명히 익숙한 개념들인데 문장들 사이 새로운 용어 하나를 발견하면 아주 새로운 세계가 펼쳐지니 혼란스럽다. 백엔드 개발을 위해서라면 단순히 웹 개발을 위한 정보 뿐만 아니라 실무에서 쓰이는 용어를 하나씩이라도 파보는 것이 좋을 것 같다. 이런 정보는 단순히 구글링으로는 이해하기 어려우니 위에서 언급했던대로 전문 서적을 다시 찾아보거나 정보처리기사로 처음부터 공부하는 것이 좋을 거 것 같다.

참고 링크

전송제어 프로토콜 TCP
HTTP 통신과 Socket 통신의 차이점
HTTP와 TCP의 차이점
HTTP와 TCP/IP의 이해
OSI-7계층, TCP/IP
NAT 개념
교차 출처 리소스 공유(CORS)
와일드카드 문자