코드 그라데이션

Proxy 구조(우회) 기본적으로 프록시 구조는 Socket 수준에서 작동한다. 그러면 실제 통신을 하게 되는 호스트가 여러 개가 되어버리는 문제 프록시는 의뢰 / 대리자 역할이라고 생각하면 된다. 웹 서버 입장에서는 누가 접속했다고 할 때, 실제로는 프록시 서버가 접속을 한 경우가 된다. Proxy 구조(서버 보호) 이런 상황일 때 클라이언트가 DNS에게 질의를 하면 a.com의 주소를 5.5.5.5라고 알려준다. 그런데 이 주소는 웹 서버가 아니고, 실제로는 웹 어플리케이션 방화벽이다. 클라이언트 입장에서는 이 방화벽이 웹 서버인줄 알고 접속을 한다. 입력은 서버 입장에서는 절대 신뢰해서는 안된다. 그렇기 때문에 반드시 검증을 함. 이 일을 수행하는 게 WAF인데 검증에는 파라미터로 넘어오는 것 뿐만..

네트워크 보안 솔루션 종류별 대응 계층 여기서 꼭 알아둬야 할 장치 L3 / L4 수준 - Inline 구조 장치 : 공기청정기 필터 역할과 유사 - Out of path 구조 장치 : Sensor 역할만 실무에서 뭐가 잘 안된다고 할 때 맞딱뜨리는 게 Packet Filtering F/W 와 IPS - 구조적으로 인라인 장치. - HTTP 통신을 감시 - 문제는 HTTPS는 암호화가 되어 있기 때문에 이런 보안 장치들이 암호화된 것은 어떻게 못한다. - 그 때 등장하는게 WAF 방화벽이다. 그러니까 Packet Filtering 방화벽이라든가 IPS라든가 이런 애들은 기본적으로 인라인 장치 그러나 웹 서버라고 부르는 것들(어파치, 엔지넥스) 등이 이런 역할을 해줄 수 있다. Inline 구조 결국 HT..

HTTP 1.0 단일 연결을 통한 단방향 통신. 각 요청마다 새로운 연결을 맺어야 했으며, 지속적인 연결이 없었기 때문에 매번 연결을 다시 설정해야 했다. 상태 유지가 어려웠고, 헤더에 버전 정보가 없었기 때문에 통신이 간단했으나 기능이 제한적이었다. 즉, 요청이 3번 오면 3번의 연결. 매우 비효율적 HTTP 1.1 Keep-Alive 연결 지원으로 단일 연결을 통해 여러 요청 및 응답을 처리할 수 있게 되었다. 이로써 연결 설정에 드는 오버헤드 감소. 파이프라인화를 지원하여 여러 요청을 한 번에 보내 응답을 기다리지 않고 동시에 처리 가능. Host 헤더 도입으로 하나의 서버에서 여러 도메인을 호스팅하는 가상 호스팅을 지원. 캐싱 기능 강화 등으로 전반적인 성능 향상. 이제 3번 요청이 오면 3번 연..

브라우저에 URL을 입력하면 일어나는 일 1) www.abc.com 이라는 주소를 입력한다. URL 에서 www는 호스트네임, abc는 도메인네임이라 칭한다. => abc라는 도메인에 속한 이름이 www라는 컴퓨터이다. ** 인터넷은 IP주소를 기반으로 접속한다. -> HTTP 통신에 앞서 TCP 통신이 가능해야만 화면이 다음으로 넘어가준다. 문제는 IP 주소를 모르니까! 찾아야한다. 2) IP 주소를 찾기 작업에 돌입한다. 내부의 host 파일을 찾는다. DNS Cache를 참조한다. DNS Query를 통해 직접 찾는다. 3) 연결된 회사의 DNS 주소를 찾는다(ex. 구글, KT 등) 4) IP 주소를 받으면 그 서버로 TCP/IP 연결을 한다. 5) 연결창구에서 GET 방식으로 http reque..

OS, User mode 와 Kernel mode H/W = CPU(연산 주체) + RAM(메모리 올라가는 곳) + SSD(2차 메모리) Kernel : 운영체의 핵심 알맹이 / 각종 운영체제로서의 제어체계가 작동되는 코드 그 위에 Process => A, B, C ...이렇게 멀티테스킹 환경이 만들어진다. 멀티가 들어가면-> '제어' 가 필요. 플랫폼 = 운영체제 + 하드웨어 플랫폼에 (아주) 의존적인 코드 => 네이티브 코드(OS나 CPU에) RAM과 SSD를 한 데 묶어서 운영체제 수준에서는 Vertual Memory 형태로 관리하게 한다. 비동기 입출력 비동기 입출력을 하게 되는 가장 큰 이유가 처리 주체에다가 뭔가를 넘겨서 맡겨가지고, 어플리케이션에서 block되는걸 막기 위함. 그래서 비동기 ..

이제 문제는, 템플릿 자체가 HTML gudxo 그러니까 HTML의 포맷을 가지고 있단 말이다. 즉 이 자체가 백엔드 개발임에도 불구하고 사용자단의 기계 형태에 영향을 받도록 되어 있으니까, 템플릿을 받아다가 뭔가 서버 작업을 해야 하고 이런 일들이 생기는 것. -> 문제 : 유지보수하기가 굉장히 까다로워진다. 그래서 이 두 개를 완전히 분리하도록 시도. 동적 문서 => 핵심은 Data. 서버는 데이터만 신경써서 보내겠다! 클라이언트 입장에서 보면 request 의 의미는 서버에게 뭔가 입출력을 해달라는 것이다. 그래서 여기서 나오는 개념이 C / R / U / D 가 된다. 이걸 통칭해서 생성된 개념이 소위 RESTful API 결국 WAS 단에서 API도 구현을 해야 한다. 구현된 API에 의해서 어..

이제 양방향으로! 양방향 상호작용 => 누가 누구랑 상호작용을 어디까지 했다더라. 어딘가에는 기록을 남겨두어야 한다. ===> 그래서 웹을 구성하는 요소가 더 늘게 된다. 상태는 전이, 이걸 기억해야 함. 이 기억이 데이터베이스다 기억은 클라이언트에서 쿠키로 구현한다. 서버는 많으니까 아예 데이터베이스를 구축해버린다. 쿠키 key-value 기억을 위해 존재하는 구현체. HTTP는 Stateless 이기 때문에, 상태 개념이 아예 없다. 그러니까 프로토콜 수준에서 전후 맥락이란 게 없다. ex. 로그인 클릭 시 정보가 서버로 간다. 반대로 오는 응답도 있다. 그림으로 살펴보면 로직을 만드는 것인데, 이 로직은 기본적으로 데이터를 가져오는 것과 이 데이터를 왜 가져와야 하고, 어떤 이유로 가져와야 하는지 ..

최초의 웹 서비스 구조 티모시 버너스 리 라는 양반이 HTML과 HTTP를 묶어서 Web이라는 구조를 만들었고, 이 HTML은 문서 형태다. 가장 기본 구조는 클라이언트가 http request를 보내면(GET 요청) 서버는 서버에 위치한 리소스를 찾아서 response를 보내준다. 그러면 클라이언트는 HTML을 수신한다. HTML은 태그를 보유하고 있는데, 이걸 해석해서 문서를 읽는다. 이제 조금 더 발전해서, 스타일 개념을 적용하게 된다. 기존 HTML에다가 스타일을 적용시키게 된다. 이제, 정적인 것에서 동적인 것도 하고 싶다. 움직임을 주는 것을 추가해야한다. 그게 Script. 최초로는 모카 스크립트, 이름을 바꿔서 Live Script, JavaScript 되었다. 자바스크립트가 중요한 것은!..