소프트웨어를 지탱하는 기술

문자열 인코딩

• 2진법을 사용하는 컴퓨터가 인간의 언어를 일정한 규칙에 따라 2진수로 변환하는 방식
• 사람들이 만든 2진수와 문자를 일대일로 대응하는 규칙을 통해 2진수로 문자를 처리
• EUC-KR, UTF-8,UTF-16,UTF-32 등

다국어 처리

• i18n : 다국어를 지원하기 위해 만든 표준.
• 프로그램 코드는 출력할 문장의 식별자만 정하고 실제 문장은 별도 파일에서 관리
• 더 이상 사용하지 않는 문장이나 누락된 문장들을 자동으로 감지

날짜와 시간

• 타임스탬프 : 컴퓨터가 시간을 표현하기 위해 사용하는 값. 단조시간이나 실제 시간을 표시
• 단조시간 : 운영체제 또는 CPU와 같은 하드웨어에서 직접 계산하는 시간. 실제 세계 시간과는 다르지만, 운영체제가 시작한 이후 시점부터 바뀌지 않는 특성이 있다. 사용자가 직접 변경할 수 있으나 시스템 재부팅 이후에는 값이 초기화 됨. 점진적으로 증가하고 외부 요인에 의해 바뀌지 않으므로 불변성을 보장하는 시간 값이 필요할 때 유용하게 사용. 두 작업 사이에 걸린 시간을 측정하거나 일정한 시간 간격마다 수행해야 하는 작업의 시간을 측정해야 할 때 사용
• 실제 시간 : 주기적으로 시간 서버로부터 값을 가져와 동기화. 실제 시간은 단조시간처럼 시간 차이를 구하거나 일정한 간격을 측정은 불가
• 타임존 : 여러 국가를 대상으로 하는 서비스를 개발할 때 반드시 타임 존이 영향을 줄 수 있는지 확인해야한다. 표준시간은 UTC. 타임 존은 운영체제 또는 모바일 기기 설정에 의해 언제든지 바뀔 수 있으며 브라우저와 같은 요청 클라이언트 설정이나 지역에 따라 타임 존이 바뀌기도 한다​

정규 표현식

범용 고유 식별자

• UUID : 컴퓨터 시스템 내에서 고유한 객체를 식별하기 위해 사용하는 값. 네트워크상에 존재하는 여러 컴퓨터를 식별하기 위해 사용하기 시작함
• 8개-4개-4개-4개-12개 구조 : 하이픈 4개와 16진수 32개

난수

해시함수

• 해시함수 : 임의의 길이의 데이터를 고정된 길이의 데이터로 매핑하는 함수. 해시 함수에 의해 얻어지는 값은 해시값, 해시코드, 해시 체크섬 해시라고 한다
• 해시함수를 사용하면 데이터양이 많아져도 일관된 성능을 보장하는 구조로 설계할 수 있고 민감한 데이터의 변조를 막을 수 있다
• 입력값이 동일하면 해시 함수로 계산한 결과도 동일, 입력값의 길이와 상관없이 해시 값의 길이는 동일, 해시충돌 확률이 낮음
• 해시함수 종류 : MD5, SHA-1, SHA-2
• 실사용 예 : 비밀번호와 같은 민감한 데이터를 보관
• salt : 실무에서 비밀번호를 저장할 때 반드시 사용해야 하는 기술.

데이터 처리 기술

JSON

• 숫자, 문자, 참 또는 거짓 등 여러 형태의 데이터를 키와 값으로 구조화된 객체에 담아 처리하는 규격.
• 가공된 JSON 데이터는 텍스트 기반이기 때문에 사람이 쉽게 저장된 데이터를 읽고 수정할 수 있고, 디버깅이 편리
• 특징 : UTF-8만 허용(UTF-8(BOM)xx), 주석을 지원하지 않음

YAML

• Yet Another Markup Language : 또 다른 마크업 언어
• 주석을 지원, UTF-8/UTF-16 지원 - 윈도우, 자바에서 만든 소프트웨어의 설정 파일로도 사용할 수 있다, 앵커와 별칭 기능
• 구조

number : 12345
pi : 3.14
str : 문자열 값
null_key : ~
object : 
  str : 문자열 값2
  object2 :
    number2: 12345
num_array:
- 1
- 2
- 3
- 4
- 5
str_array:
  - one
  - two
  - three
  - four
  - five

XML

• 웹에서 규격화된 데이터를 효율적으로 주고받기 위해 만든 마크업 언어
• 특징 : 텍스트 기반 데이터, 문자 인코딩을 직접 지정할 수 있다

프로토콜 버퍼

• 프로토콜 버퍼(Protocolbuf) : 구글에서 만든 직렬화 규격
• JSON, YAML, XML이 텍스트 기반 규격인 반면, 프로토콜 버퍼는 바이너리 기반 규격이기 때문에 더 빠르고 효율적으로 데이터를 가공하고 처리할 수 있다
• 실시간 온라인 게임처럼 제한된 짧은 시간 안에 수많은 클라이언트가 요청할 때 텍스트 기반 규격은 처리 성능 때문에 병목현상이 발생하므로 프로토콜 버퍼와 같은 바이너리 기반 규격을 사용해야 한다
• 특징 : 바이너리 형태로 데이터를 가공해 저장된 메시지나 파일을 사람이 읽을 수 없다
• 메시지 규격 코드화
  • 스키마파일(.proto) : 프로토콜 버퍼에서 사용할 메시지 구조를 정의, 사용하는 프로그래밍 언어와 관계없이 공통문법
  • 프로토콜 버퍼 컴파일러 : 스키마 파일에 필요한 언어를 인터페이스 코드로 만들어주는 프로그램
  • 인터페이스 코드 : 컴파일러가 스키마를 읽어 만들어낸 결과물. 모든 프로그램은 이 코드를 통해서만 데이터를 직렬화/역직렬화할 수 있다

Base64

• 바이너리 데이터를 아스키 코드 일부와 일대일로 매칭되는 문자열로 단순 치환하는 인코딩 방식
• 치환한 데이터의 길이는 기존 데이터 길이보다 약 30% 정도 늘어나는 단점이 있지만, 바이너리 데이터를 문자열 기반 데이터로 취급할 수 있다
• ex] JSON과 같은 문자열 기반 데이터 안에 이미지 파일을 포함해야 할 때 Base64로 인코딩하면 UTF-8과 호환가능한 문자열을 얻을 수 있다
• 비트 배열이 3바이트로 나눠 떨어질 때까지 0을 추가하고 추가된 바이트 수만큼 패딩(=)을 붙인다
• 데이터 길이를 명시적으로 구분할 수 있는 JSON이나 HTTP 메시지 바디에서는 패딩이 필요없지만, TCP처럼 스트림 형태로 데이터를 주고받는 환경에서는 패딩이 필요하다

데이터 압축(zlib)

• zip 확장자 파일 : DEFLATE 알고리즘으로 압축된 파일
• zlib : DEFLATE 알고리즘을 제공하는 라이브러리,
• DEFLATE(압축) - INFLATE(압축해제)
• 압축원리 : 데이터의 공통된 부분을 찾아 하나로 묶은 다음, 그 정보를 저장
• 손실압축 : 압축할 때 원본 데이터가 손실되기 때문에 압축한 파일을 재구성 할 수 없지만 압축률이 매우높음, 멀티미디어 분야에서 많이 사용
• 무손실 압축 : 원본 데이터를 100% 재구성할 수 있다. DEFLATE 알고리즘이 무손실 압축 알고리즘
• 압축률이 높을수록 원본데이터/압축데이터해제시 더 많은 CPU 자원을 사용한다, 압축 알고리즘은 기본적으로 압축이 끝나기 전까지 압축될 파일의 크기나 압축률을 알 수 없다.

웹을 지탱하는 기술

HTTP

• 서버와 클라이언트가 텍스트, 이미지, 동영상 등의 데이터를 주고받을 때 사용하는 프로토콜
• HTTPs​ : 데이터를 안전하게 주고받기 위해 전송계층보안(TLS)를 더해만든 프로토콜
• 무상태성 : 요청 메시지를 보내기 직전까지 대상 컴퓨터가 연결 가능한지, 메시지를 응답할 수 있는 상태인지 알 수 없음

HTTP	TCP
상태가 없는 프로토콜	상태가 있는 프로토콜
요청과 응답이 일대일 대응	연결을 끊지 않고 명시적으로 연결을 닫기전까지 계속 메시지를 주고받음
TCP 프로토콜 기반 + 텍스트 기반의 헤더, 메시지 - 패킷 크기가 큼	바이너리 데이터를 사용, 패킷 크기가 상대적으로 가벼움. 많은 사용자를 처리하기에 유리
각 요청이 소켓 1개를 점유	모든 요청이 소켓 한개를 사용하기 때문에 요청이 섞일 수 있음.
로직이 간단한지만 TCP보다 느림	빠르지만 개발자가 연결상태를 직접 관리해야함

• 요청메서드​ : GET, POST, DELETE, PUT, ...
• URL​ : 웹주소, 요청주소. HTTP에서 통신할 대상 컴퓨터를 식별할 때 사용. '사람이 기억하기 쉽게' 만든 식별자
• DNS(Domain Name system) : 컴퓨터가 실제로 통신할 때는 IP를 사용하기 때문에 URL을 IP주소로 변환하는 작업이 필요함
• DNS 라운드로빈, DNS 로드 밸런싱 : 하나의 URL이 여러 IP를 가져서 클라이언트가 IP 주소를 요청할 때마다 여러 IP중 하나를 보내줌으로서 서버 부하를 줄일 수 있다
• 요청헤더
  • Host
  • Accept : 클라이언트가 처리할 수 있는 데이터 형태
  • User-Agent : 웹 브러우저 프로그램 정보, 웹서비스는 브라우저마다 지원하는 표준이 조금씩 다르고, 지켜야할 표준이 많다
  • Content-Type : 메시지 바디의 형식을 알 수 있는 키워드
  • 메시지 바디 ​: 실질적인 요청 데이터를 담는 데 사용, 단순 문자열 외 이미지, 동영상, 파일과 같은 바이너리는 Base64로 인코딩, GET,OPTIONS 메서드는 메시지 바디를 사용할 수 없다
• HTTP 응답은 상태 코드와 메시지를 포함한다
• 쿠키 : 클라이언트의 상태 정보를 로컬에 저장했다가 참고, Response Header에 Set-Cookie 속성을 사용하면 클라이언트에 쿠키를 만들 수 있고, 사용자가 따로 요청하지 않아도 브라우저가 Request 시에 Request Header에 넣어서 자동으로 서버에 전송
• 세션 : 쿠키를 기반으로 하지만 사용자 정보 파일을 서버에서 관리, 세션은 만료시간을 정할 수 있지만 브라우저가 종료되면 자동으로 삭제됨, 쿠키보다 보안이 뛰어나지만 서버에 부하를 줄 수 있다
• 스티키 세션 : 하나의 브라우저는 하나의 웹 서버에만 연결하게 됨, 로드밴런스(부하가 가장 적은 웹서버로 연결)는 첫 요청, 즉 쿠키가 없는 요청이 들어올 때 쿠키에 값을 등록하고 웹 서버를 지정한 다음, 이후 요청이 올 때 세션 값을 기준으로 다시 연결할 웹 서버를 구분, 세션 유지 기간도 함게 설정. 쿠키 만료 시간보다 길게 설정하는 것이 좋다
• CORS(cross-origin resouce sharing) : 교차 출처 리소스 공유. HTTP 서버의 웹 페이지, 이미지 파일이나 API 등을 특정 호스트로 접속한 웹 브라우저만 사용할 수 있게 제한하는 정책
• 아파치와 Nginx : HTTP 표준에서 정의하는 기능을 바로 사용할 수 있는 웹 서버 소프트웨어
  • 아파치 : 사용자 수가 늘어날수록 처리가 비효율적인 다중 프로세스 구조 사용
  • Nginx : 수평적 확장에 유리한 단일 스레드와 이벤트 기반으로 동작, 아파치보다 많은 사용자를 처리할 수 있다

RESTful API

• 서버와 클라이언트가 메시지를 주고받을 때 사장 많이 사용하는 통신규격
• 요청 주소와 메서드, JSON 규격을 이용하여 API를 정의하고 사람이 읽기 쉬운 형태이기 때문에 범용적으로 사용

HTTPS

• 요청 주소와 메서드, JSON 규격을 이용하여 API를 정의하고 사람이 읽기 쉬운 형태이기 때문에 범용적으로 사용
• TCP 대신 전송 계층 보안(TLS) 프로토콜을 기반으로 하는 HTTP
• 서버와 클라이언트가 주고받는 메시지를 암호화하여 제삼자가 볼 수 없다. 메시지를 암호화/복호화할 때 사용하는 키는 HTTPS로 메시지를 주고받는 두 컴퓨터만 안다

OAuth 2.0

• 데이터를 간편하고 안전하게 주고받기 위해 만들어진 표준
• ID와 비밀번호 대신 Access Token을 기반으로 사용자를 식별, 이 토큰은 API를 제공하는 리소스 서버만 발급할 수 있으며 일정 시간이 지나면 폐기될 수 잇다.
• 모든 토큰은 필요한 권한만 지니게 할 수 있어서 OAuth를 이용하면 서버는 클라이언트의 접근 권한을 쉽게 제어할 수 있다
• 리소스 소유자 : 리소스 서버에서 제공하는 기능을 실제로 사용할 주체이자, ID와 비밀번호를 이용해 리소스 클라이언트에게 권한을 인가하여 액세스 토콘을 획득하게 될 주체
• 리소스 클라이언트 : 리소스 소유자로부터 사용 인가를 받아, 소유자 대신 액세스 토큰을 획득하며 액세스 토큰을 사용해 리소스 서버의 API를 사용하는 주체, 페이스북이나 구글 인증 기능을 사용하는 다양한 모바일 앱, 웹서비스가 해당
• 인가 서버 : 액세스 토큰과 인가 코드를 관리하는 서버
• 리소스 서버 : 보호된 리소스를 관리하며 리소스 클라이언트가 사용할 API를 제공, API를 사용하기 위해 액세스 토큰이 필요하며, 리소스 서버는 액세스 토큰이 유효한지 확인하기 위해 인가 서버와 통신을 주고 받기도 함