2주차 수요일 그룹 2
| Group 2 | 김준기, 강승훈, 김현수, 이경민, 고동훤, 윤중진 |
확장자명에 대한 MediaType 반환 로직에 대해 고민했습니다. Enum으로 관리하는 방법, Switch문으로 관리하는 방법, Resolver 클래스에게 위임하는 방법을 고려했습니다.
Enum 혹은 Switch문으로 관리해도 좋지만, 조금 더 다양한 관점에서 학습을 해보고 싶었습니다. 스프링에서는 어떤식으로 처리했는지 참고하고 싶어서 코드를 살펴봤고, 실제로 MappingMediaTypeFileExtensionResolver클래스로 처리하는 로직을 학습할 수 있었습니다. 이를 차용하여 Resolver 클래스에서 처리하도록 구현을 진행했습니다.
public class MappingMediaTypeFileExtensionResolver {
private final Map<String, HttpMediaType> mediaTypes;
public MappingMediaTypeFileExtensionResolver() { // initialize .. }
public HttpMediaType resolve(String extension) {
if (mediaTypes.containsKey(extension)) {
return mediaTypes.get(extension);
}
throw new IllegalArgumentException("Unknown extension: " + extension);
}
}전반적 구조에 대해 고민하고 설게했던 내용과 이렇게 설계했던 이유를 공유 및 설명하는 시간을 가졌습니다. 추후 고민해야할 내용 중 GET, POST 등 메서드에 따라 분기처리를 해주어야하는데, 이에 대한 구조적 고민은 아직 현재 진행중이며 여러 래퍼런스를 통해 인사이트를 얻을 필요가 있겠습니다.
스레드풀을 사용할 때 Core 크기와 Max 크기 및 BlockingQueue의 전반적 동작 과정에 대해 알게 되었습니다. 또한 RFC 문서를 꼼꼼히 확인하는 크루를 보며, 이를 배우고자 합니다. WAS 서버를 만드는 입장이기에, 악의적인 사용자가 Request Body의 길이를 너무 길게 보내는 경우, 헤더의 CRLF 또는 LF가 와도 서버는 처리해야할 수 있어야 한다는 점, HTTP 이전 스펙에서는 헤더 Value에 개행문자도 포함될 수 있다는 점을 공유받으며 간단히 학습할 수 있었습니다. 또한 스프링에 국한되지 않고, Go Gim 프레임워크의 Router 메커니즘을 시도하는 모습을 보며, 보다 다양한 관점에서 생각해볼 수 있는 좋은 시간이었습니다.
- ExecutorService.submit() 활용
- 요청 데이터를 byte 배열로 읽어서 처리하려다 보니 진행 상황이 많이 늦음
- 단순 구현 보다는 로우 레벨에 대해 잘 아는게 중요하다 생각하여 소켓에 대해 학습하는 시간이 더 많았음
- 다들 구현을 빠르게 하고 그 와중에 구조를 잘 잡아서 배울 점이 많았다.
- 규약을 나름 지키려고 하지만 생각보다 잘 지켜지지 않는 것 같다.
- step-3 까지 요구사항을 만족하도록 간단히 구현했음
- GO gin 프레임워크의 구조를 따라하도록 router handler 방식으로 구성했음.
(없음)
- 다른 사람들은 RFC 문서를 완벽히 만족하거나 제약사항을 더 두어 구현한 것 보고 따라해야겠다고 생각이듬
- 2번 과제까지 완료했습니다!
- Handler를 활용해서 Request, Response를 관리하고 있습니다.
-
Executors.newCachedThreadPool()를 활용해 Unbounded ThreadPool을 사용하고 있습니다! -
HttpRequest에서 Request 파싱을 진행하고 이 값을 기반으로HttpResponse를 생성 및 반환합니다! - 3번 과제 구현에 대해서 고민중에 있어요...
- Q. 스레드 풀 관련해서 어떻게 설정하셨나요?!
- A. 이경민 2주차 학습일지 7월 2일자 로그를 확인해주시면 자세한 내용을 확인할 수 있습니다 :D
- 확장성 좋은 서버 구현을 위해 구조 잡는중
- Client class에서 보다 용이하게 header를 조회할 수 있는 방안 고민중
- 구조 잡는데 너무 많은 시간에 소요된다. 너무 지나친 확장성까지 고민하지는 말자.
- header field-value는 CR/LF를 포함해서는 안된다. 또한 header 마다 상이한 rule을 가지고 있어서 받아온 값을 parsing 하는 과정에 검증이 우선되어야 한다.
- Reader를 직접 구현힐 필요성을 잠깐 느꼈지만, 너무 복잡해질 것 같아서 BufferedReader를 사용하기로 함. (다만 BufferedReader에서 CL/RF를 어떻게 처리하는지 한번 확인해보아야 할듯)
- header에서 Map<String,String>로 가지고 있자. 대신 헤더를 조회하는 쪽에서 뜯어보기 곤란할 수도 있겠다.
- CachedThreadPool로 비동기 처리
- 규약을 최대한 지키자
- 이번에 response header 뒤에 CRLF를 안해줘서 모든 응답이 웹 브라우저가 이해할 수 없게 되었다.
- 이거 찾느라 하루밤 다 날렸다..
- 무한대의 요청이 올 경우를 대비해, MAX BYTE SIZE(header, body)를 정하였다.
- ThreadPool size를 정한 기준? 딱히 없음. 실제 서버 스펙에 따라, tps에 따라 전부 다름.
- Handler.getHandler()을 어떻게 하면 좋은 방식으로 핸들러를 찾을 수 있을지 고민해봐야 함.